Are we, for the folks that can see over the screen there, are we on the record right now?
Is the transcription running?
Okay.
So here's the thing.
With the transcription, you guys know that this is new this year, and I think it's been
very, very cool.
And I've had a lot of questions about how it's working, because it is so darn effective.
So the way that that's actually happening is there is a live participant of Party Track
that is not here.
They are off-site, and it's a court reporting service.
So ponder that.
So when I'm not at DEF CON, I'm an attorney back home, and court reporters obviously sit
there and transcribe court proceedings and depositions and very bland and boring types
of materials.
So there is a team of court reporters that has now gotten to transcribe this for all
of us and type the words that have been coming out of all these speakers.
And they have cute little mouths like Dongs, pumpkin poop, booze.
Okay.
So it may be one of the more interesting types of projects that they've ever been assigned
to.
So my question to our court reporter is, what do you think?
Okay.
Thank you.
Thank you.
Thank you.
So how about just one more time for our court reporter here in party track, let's make applause
show up on that screen.
Awesome stuff.
I'm going to be taking off pretty soon.
You guys have been great.
Party track totally rocks and I will probably see you all next year.
Without further ado, we are going to learn something about exploitation detection systems
now.
Have a good time, everybody.
Hello, guys.
Hello, girls.
Today I will talk about exploitation detection.
First, I am Amr Sabet.
I am from Egypt.
I am a malware researcher at QCert in Qatar.
I am the author of some open source projects like SRDF.
I will talk about SRDF today and book 66 emulator.
I wrote a malware analysis paper in Stuxnet about Stuxnet and that's it.
That's my first time here in the U.S.
So thank you for giving me this chance.
Okay.
Let's begin.
As you all know, been testing right now or hacking right now become different from the
security compliance that we had like they are not attacking the servers right now.
They are not trying to use me to hack the servers.
They are trying to exploit and attacking the server using all of these techniques.
Right now, most of the attacks are advanced resistant threats.
They are attacking from the client side.
They are using the phishing.
They are attacking the employees of the company.
And from their clients, from their machines, they are attacking the servers.
So they can bypass most of the servers.
They are using security compliance applications, firewalls, our intrusion protection system,
intrusion prevention system.
They can bypass everything.
They use some undetectable malwares, infecting the clients, using HTB connection, HVS.
So they are bypassing everything.
They are bypassing also the anti-viruses and all of the security tools right now become
useless.
So what's the solution?
What is the new technology?
What's the new idea?
There is no error.
That's what we are talking today.
The next security technology is from my point of view is the exploitation detection system.
We are now need to secure the client like we are securing the server.
We need to secure from the client side attacks and exploits.
We need to stop the successful exploitation, stop the using of zero days and make it harder.
Actually, when the security began, they began with anti-virus as a whole technology,
the wow technology, and after a time it was bypassed and there is another attacks.
They created the firewalls and become very, very powerful.
And after a time, bypassed, so they are creating the intrusion detection systems and intrusion
prevention systems and they are now bypassed.
So what's the next?
The next is security.
The next is the exploitation detection system.
That's the error of exploitation detection system.
Today I will talk about the exploitation detection system as a new technology, as a
new concept.
That's what I already talked about.
I will talk about also my tool, my exploitation detection system tool, how it can stop the
attacks, how it can mitigate the attacks.
I will talk also about the development.
It's still in the middle.
But it's still in the middle.
But I will talk about what we reach until now.
And I will have a little bit of advertisement for my open source development framework.
I will talk about it also.
How many people here know about assembly exploits, understand all of this?
Good.
Not too much.
But I will explain everything from zero.
Okay.
No problem.
Okay.
First we will talk about why EDS, the goals of this tool, how I created all of this.
Then I will talk about the design of this tool and the mitigations that it used inside
EDS to stop all the attack vectors.
And I will talk about the attack vectors, explaining them in details, not in brief,
not huge details for everyone to understand.
And I will talk about the monitoring system.
It's also inside EDS.
And then the development and my future point of view for EDS.
Let's begin.
Simply as I said, it's created merely to stop the exploitation as I see most of the
attacks now using social engineering and the exploitation, the attacks and all of this.
So that's what I created this tool for.
memory corruption exploits. I know maybe you don't know about memory corruption. I will
describe it right now. It detects the compromised processes if you have an auto breeder and a
malicious video file running it. And it also exploits your process. So it tries to detect
that this process was compromised to an unknown behavior or has some corruption in its
memory and it stops that. It prevents or alerts someone in the company, the IT administrator or
the security team about there is a machine or there is a client that has been hacked.
Simply, memory corruption is about if you have a piece of memory and there is a buffer created
for, there is an application that is being hacked and you have a memory that is being
deleted. So it takes the user name and password and he imagines that maximum your name will be
200 characters. No one has a name longer than this. So it creates a buffer for it and take your
user name, copy all your user name inside this buffer and he don't check on the size of your
user name and then run. Actually if I send a user name with 1,000 bytes, it will run the
same thing. If I send a user name with 1,000 bytes or so, 1,000 character length, he will write
on the 200 bytes of this buffer and then he will override some other places in memory. This
places in memory could be if you are could be a pointer to a place in memory, could make some
corruption. Could be a pointer in a code in the stack, something in the stack has a pointer
so if you make a pointer named return address, the processor or the CPU, after a time, execute, go
through this pointer and execute the code that this pointer points to. If I override this pointer, I
can make the CPU go to another place in your application. So if it's something that checked
the password, I can override this pointer and make it return the return address of the CPU in the
name and password are correct. So I can change the behavior of your process using some
modification in your memory. And that's what's named memory corruption. You can know about it
more in Corland. Corland team is a very, very good team. Has 10 exploits talking about
memory corruption vulnerabilities, how to use it, how the people use it. And as you see in
these pictures, I show you that there is an overwrite. He overwritten the return address as
you see. So I can now modify the behavior of this process. Okay. Some people will ask, okay, it
is a good point, but what's the difference between the system and the antivirus?
Simply, EDS is not signature based. It's not mainly behavior based. It's simply searching the
memory for any corruption. If there is unknown corruption or unknown overwrite, it can detect
that. It doesn't detect malware. It's not to detect there is a new virus or something. It's just
search for exploitation.
Okay. So there is something before EDS. There is something new? No. There is
compile time solutions and the compile time solutions was created by Microsoft like GS cookie.
They add a cookie before the return address that we saw in the previous slide to check if it was
overwritten or not. And then you can see that there is no overwrite. So you can see that there is
no overwrite in that. So we can see that there is no overwrite. But the compile time
solutions has a problem. That it force everyone to recompile the application to add this
feature. So always there is an exceptions. There is will be someone developer will not compile
with the new technology. So I can buy puzzles. There is other runtime solutions. One of them was
who talked about his great tool from two presentations. And there is others. Actually,
from my point of view, I see it's like on-off mitigation. It's you are ‑‑ this action is a
malware or there's an exploit or that's not an exploit. I need something more flexible. It's
one layer of mitigation, one layer of defense. He can't know that he was bypassed or not. I
will talk about this. Okay. So what we have? What we have ‑‑ what new things we have? We
have cooperative mitigations. We will talk about this. We have a schooling system. We have
something more flexible to the system. We have a system that is more flexible to the system.
It detects exploitation and so on. We have additional layer of monitoring system. And this
monitoring system, we'll talk about it. It detects if there is something bypassed the attack,
bypassed all mitigations. And there is an attack already working. So it's another additional
layer to secure. Assembly, the design that there is payload detection. We'll talk about what
is shield code and what's not shield code. We'll talk about what's not shield code and what's
robot chain. We have shield code detector. We have robot chain detector. After that, we have
the attack vector detector. We have security mitigations for the stack and with heap.
Actually, the stack, as we saw in the two slides, it's a place to include some return addresses.
And this return addresses, if it was overwritten, it will create a problem. It can change the
behavior of the application. The heap has something similar named Vtable. Vtable, actually,
it has some pointers of some functions in the time the processor can execute one of them. And if
they are also overwritten, it will create a problem. After that, we have the scoring system and
the monitoring system. Okay. Assembly.
The scoring system is based on three things. Based on payload detection. Based on shield code.
Based on what you sent in your input. If you sent a code or something like this. If you send a
robot chain or return address. Also, it includes, it detects the exploitation attack vector.
If there is an attack way he did. If there is something suspicious, it tries to stop this.
Also, it scans on something suspicious related to this process. Like Adobe Reader connect to
unknown websites or create a new process named command.exe. That's a suspicious action. So it
gives more score or higher score for this attack or this input. There is also a scoring system.
There is something more suspicious. Okay. The monitoring system simply searching for evidence
of exploitation. Detects there is a bypassed or ready mitigation. This process was compromised.
They include, like, unknown dealers. There is some functions hooked or something like this.
There is something unknown running in this process. We will talk about that.
In details. First, what's shield code? Simply, as I told you, that I can send user name 1,000
bytes. But I can override a return address. And I can also modify this return address to return
to my user input. To return to my user name. So the processor will execute my user name as a
code. So shield code is simply some bunch of bytes I can send as it's a user name. And actually
it's an assembly code in bytes. So I can, when I can modify the return address, I can make the
processor execute my user name or execute the bytes, this bunch of bytes. And this bunch of bytes
do an action for myself. So I can control your process. I can send you a code. And this code will
get executed. And I am like I am inside your PC. The shield code simply it's first it gets its
place in memory. That's the first thing to do. Because it's running in unknown space. It's just
an unknown buffer. So it tries to take where it is. And then getting the Windows functions to
execute. Like I need to execute a new application. I need to create command.exe. I need to
connect to the Internet. So it gets the Windows functions to do all this. And then attack.
There is a good article about it. A good project. You can check it. It's a good article. I can
problem until now? Actually, some shell codes are forced to not have any null byte or zero.
Why? Because when I send a user name, the user name always is just a string or a text.
So the text in Windows finished with null byte or zero byte. That means that user name,
your user name was finished. So the shell codes should not have null bytes. That's a point or
most of them. They are sometimes encrypted. If you see Metasploit, how many people here use
Metasploit? A lot. Actually, Metasploit, when you choose the payload, choose a shell code,
you can encode it to bypass a shell code. You can encode it to bypass a shell code and
you can use it to bypass antiviruses and all the signature based ways. So sometimes
shell codes are encrypted. And there will be like a loop trying to decrypt it byte by
byte. So there will be a loop. Some code executes in like a cycle. And some shell codes are
forced to be nasty, like they are characters A, B, C and so on. Because some applications,
that check the user name include some unknown bytes. That's it. So we need to detect that
this user name, this person name includes some shell code, includes some code inside
it. And it try to modify the application behavior to run this shell code. So I created a little
detection tool. My goal in this tool is to be very fast because this input will be sent in
small time and an action will happen after that. So I don't need to have a memory console in
time use. I need it to be very hard to bypass and to be very strong and have some false
postures but low as I can. So I added static shellcode detection. Static shellcode means
just maximum disassembly or just check the bytes. It doesn't try to when it detects the
shellcode, it doesn't run it. That's the static. It doesn't run the shellcode. It just
scans it, disassembles it, converts it to assembly and tries to understand if it's really an
assembly code or just a bunch of bytes. And we divide this shellcode detector into three
phases. The first phase that we search in this user name, an indication there is a code, a
working code. And we will detect how we can do this, like we detect there is a loop, a working
loop inside. There is something that's if I disassemble all of these instructions, I find
jump to one of these instructions and the code is simply working. That's the first
indication of possible shellcode. The second, I filter all of the instructions that
are invalid or some instructions that are corrupted or not used in the normal
processes and then I do some flow analysis on all of this shellcode. If this code will work
fine or it will not work, it's just a bunch of bytes. Thank you.
Why did you stop speaking? Let's take a break.
All right. You know the drill. What are we called? No, it's not fuck the
speaker. I don't know what it is. Shot the noob. What are you doing?
What are you doing?
All right. Oh, and we need ‑‑ we need ‑‑ who's the first time ‑‑
I think the guy here in front actually got there first. All right. Who are you, sir?
Wait, wait, wait. I'm going to interview him.
What? Oh, yeah, we have to interview him first.
What's your name?
Where are you from?
Utah.
Why did you come to DEF CON?
Why are you drinking?
Because I'm not Mormon.
Why are you in Utah?
All right. Cheers.
All right. Cheers to everybody. First time at DEF CON.
How's he doing? How's he doing? Should we invite him back next year?
That was a big one.
He had five minutes.
Yeah, exactly. We're taking this?
I will take it.
Is this yours?
No, no, no. It's not mine. I'm just joking.
That's awesome. I don't know, but we'll just leave it there for the next few years.
Thank you.
Thank you. Thank you, guys.
What did we say?
That's the shell code detector.
Okay. We searched for indication of shell code. First, we searched for a working loop.
How it works?
Actually, the assembly code for x86, each instruction has a variable size, like instruction has three bytes, instruction has five bytes, and so on.
So what we are doing is we disassemble from a place to our research program to something previous and disassemble between all of them.
If the assembly code works fine, that doesn't mean it's working.
The last instruction ends before the jump.
So it means that it's something, it's a real loop.
So the jump is here, pointing to an instruction, and all of these instructions were running, and we'll return to this jump, and so on.
We searched for something like this.
It seems that it's a working loop.
That seems a shell code.
That's just an indication.
We check for...
In some shell codes, they call to something to address in previous.
Why?
To try to using a simple way to get where they are in the memory.
I don't know.
I don't need to enter the details, but we can detect there is a call to something previous and disassemble between the call and between the destination.
So we can know that it's...
It seems a working loop or something like this.
We check also in some loop instructions inside the x86.
That's the first way to indicate there seems a shell code or something.
Then, if we didn't find the loop, we search for high rate of a known instruction named push.
Usually it was used in the shell codes that it must be an ASCII.
It must be an ASCII.
It's a B2B characters.
A, B, C.
Something like this.
And we detect there is a high rate of these pushes.
And after that, usually the shell codes that include pushes, the push instructions save a value inside the stack.
So if you have hundreds of pushes and then call to the stack, it's simply...
It could be like an encryption way or a shell code encrypted.
And we'll decrypt all the shell codes in the stack and then call to it.
So we can detect something like this.
And also we have an instruction named fisting.
That's an assembly instruction.
But it's used very much with shell codes because it detects where there are the shell codes.
So with all of these three ways, we can see that it seems a shell code here.
This assembly or this person name is suspicious.
Then we skip some invalid instructions.
Some of these instructions in, out, and all of this are related to devices and are used in the kernel mode of Windows.
Used by the device drivers.
Not used by normal applications.
And some of them, some instructions has unknown behavior.
Some crazy things.
In Intel assembly.
But we skip all of these instructions if we found them.
So the shell code...
So if we found the shell code has these instructions, it seems corrupted or something.
And then we do some flow analysis.
Simply, if you have a loop, the loop should have...
If it saves something in the stack, it should get the value that it saves in the stack.
Because stack is like a cup of water.
You add to it and then you take from it.
So you can't fill it until it overflows.
You just need to add to it and then take what you added.
So if you have a loop, you should have push and pull.
You should have something add in the stack and another instruction take from the stack.
So we check on this.
We check on compare and jumps and all of this.
We check for the null three bytes.
After this, after I designed this shell code and after I wrote it, I tested it in some false positives and some real shell codes in Metasploit.
For the false positives, I detect that 4% of the shell codes...
For 4% of junk data, it detected as a shell code.
It's not a very high level of false positives, but not few.
But it detects all Metasploit shell codes.
It can detect them.
It can detect the shell storm shell codes, famous sub-site for shell codes.
But actually, manual evasion is still possible.
It's a simple return oriented programming.
And as you can see, it's simply when there's some mitigation windows created in data execution prevention.
Prevent the users from prevent any data sent as user name or something like that to be executed.
So some people try to return inside the application.
And try to find very few instructions.
After this instruction, the return instruction.
And to make a call return.
Call return.
Or return to some instructions.
And then return to another some instructions inside the code section of the application.
And another and another.
And collect these small pieces together to create a working shell code from the code of the application.
So it can bypass the data execution prevention.
And it can have a working shell code.
We detect all of them easily.
We check if the address is in the executable module.
We check the return after a call or not.
And all of this.
Okay.
For the stack mitigations.
We detect there's ‑‑ we have a mitigation named wrong module switching.
And it's simply ‑‑ we detect that there is ‑‑ there is a return to a Windows API.
The Windows functions or Windows APIs are some functions created to ‑‑ created by Windows to do some stuff like creating a new process or something like this.
We check if there is a call to it or it's a return to this call.
If there is a return to this API, so it seems a return‑oriented programming or seems an attack.
We talk about return, robot attack.
Most of the ‑‑ of this type of attack vector, what they do to bypass that execution prevention, they create some pieces of ‑‑ of ‑‑ of robot attacks or robots.
As we described it, some piece of codes.
This piece of codes.
We call to a virtual virtual protect API or some other APIs.
Virtual protects can make the stack executable.
So they can use the robots to create ‑‑ to call to virtual protect to make the user name that I entered as a shell code or the shell code inside my user name become executable.
So I can return to the shell code and bypass that execution prevention.
So what we do is we hook the calls to the system.
There is a kernel mode that includes the Windows device drivers and the process.
The process connect to the Windows kernel mode using instruction in system enter.
We are hooking here and do stack back tracing.
Check every caller to this ‑‑ to system enter.
Check the caller to system enter.
And the caller to the caller.
Until we reach if there is a call from the application to this API or there is no caller.
So it's return oriented programming.
Actually, in Windows 32, we can hook the SSD hooking.
But in Windows 64, we don't ‑‑ we can't create a device driver that hooks the SSD hooking.
So we hook the Windows emulator.
Wow 64 emulator.
We can hook any function calling to the kernel mode system enter and something like this.
We hooking virtual protect and all of this protection APIs.
And the ‑‑ the ‑‑ the creating process.
And shell execute that could execute an application.
So I can ‑‑ so the attacker can execute.
For example, we hook these functions.
We hook the functions that will create a socket or connect to the Internet.
And all of this stuff.
What we do exactly after we do the back tracing and reach the call to this application,
the call to this API in the application,
we check if this call is really a call to this API or that's a fake return address created by the attacker.
We do some checks like we check if there's a call to this API or not.
We check the parameters.
If that's ‑‑ if really what we saw in the parameters are the parameters that created by this API caller.
The application call to this API with these parameters or not.
We will see this again.
We check if the application itself has a call to the function calling to this API.
We check another things.
And after that, we give a score to this API.
Yes, that's a call to this API or not.
We check on different type of calls to detect there's really a call to this API.
We check there's the parameters.
We check if really there is a constant parameter.
The process give it to this API like it gives a parameter like gives the name of the process actually.
Create process has a create process API.
And it gives to create process API a parameter, a specific application.
And the attacker try to use this part of the code and try to give it another parameter.
We can detect something like this.
We will see right now.
Let's see the demo.
Sorry.
I hope it can work.
Anyone see anything?
Anyone see anything?
Okay.
I don't see already.
No problem.
Simply, we begin by ‑‑ we have Firefox API, Firefox application.
And we try to ‑‑ okay.
We try to hook this API and hook the Firefox and check if we ‑‑ if we run an application
using Firefox, we can check if we run an application using Firefox.
If there is a real call to this API or not or this ‑‑ it's really Firefox who run
this application or it's a fake call or something.
We first hook the application and then we here click the application in Firefox.
So we force Firefox to execute our application or create a process.
And then we check on the parameters of this.
I don't see the video, but no problem.
We check on the parameters.
We check on the call stack.
We do some stack back tracing and check on the call stack.
And check on the parameters.
It checked the score.
And we saw the score is two.
So it's a normal call.
And then ‑‑ I don't see anything.
But ‑‑ okay.
Sorry.
I made a ‑‑ I made a vulnerable application, small vulnerable application, which not call
to shell execute.
It gives an input and return to shell execute.
So ‑‑
Okay.
I tested it.
Okay.
I run the application.
And it's ‑‑ it gives the message that in the call, in the code.
And then it should return to shell execute, which execute a function.
So we check this.
And it detect there is a ‑‑ there is no call.
And ‑‑
Okay.
It detect there is an attack and gives a high score so it can stop this attack.
And then we have a CH mitigation simply.
We check the instructions, exception handling is working fine.
And then we have some mitigations for HIP.
We detect the HIP overflow, HIP spray, HIP user after free.
We hook the Gmail log, the global log, the functions that are located in the HIP on all
of this.
And we detect that we add some cookies on each allocated buffer and try to detect if
there is an overflow to this buffer in the HIP or not.
And for HIP spray, we try to detect there is an overflow.
We have a large memory allocation in very small time from the same module and try to
stop this HIP spray.
We scan for shell code and robot chain.
If we found the shell code and robot chain inside, so it's simply HIP spray.
And we detect use after free.
For ‑‑ we detect there is a use after free.
If there is a clause including some pointers or creating something in V table, we try to
make this buffer.
Freed after ‑‑ we delay, it's free.
So we can ‑‑ we can stop any use after free.
And then we have the scoring system.
We describe the scoring system.
We stop the ‑‑ this all type of attacks using our scoring system.
We try to detect the payload and the attacking vector and all of this.
And then if we ‑‑ if we didn't find it's a real attack.
We can at least mark it as suspicious and give it to the ‑‑ the ‑‑ the administrator.
We have the monitoring system.
And the monitoring system check if all of our mitigations was bypassed.
We check the executable place in memory.
We check ‑‑ check if there is executable place in stack.
There is executable place in HIP.
There is executable place in memory map defies.
So it's something suspicious.
We search for robot chains in the memory.
And share codes and all of this stuff.
We check if there is a thread running outside ‑‑ running outside the memory and all of this.
What we are planning for, we are planning to create to ‑‑ in any company to have a central server.
Which get all the logs from all of the exploitation detection system applications inside the clients inside the company.
So they can get some information from all of this.
Detect.
If there is a suspicious action happened on all of the clients.
And then using also, create all of this information with the intrusion detection system.
And all of these tools, they can create a timeline of an attack.
They can detect there is an attack and contain it.
That's the future work.
Okay.
Thank you.
The development is based on security search and development framework.
It's a development framework already created.
Until now it's included three contributors.
It's simply it's a development framework.
It's for Windows right now.
And we couldn't include a version Linux and version Python.
Simply.
It's a development framework for writing security tools.
This development framework includes a bunch of security tools inside it.
It includes a PE and ELF parser.
It includes a PDF parser.
It includes an Android parser.
It includes for static analysis a full assembler and disassembler engine.
And Java disassembler.
It includes some wildcard scanning and all of this.
It includes for dynamic scanning, full process analysis, debugger, full debugger, and an emulator.
It includes for behavioral API hooking and all of this.
Simply, it's a development framework.
You can build your application using it.
You will not waste your time.
If you have an idea and you need to implement it, you will not waste your idea.
You can use the .
And implement your idea easily.
And don't waste your time creating and reinventing the wheel and creating all of the tools.
We have network analysis.
We have packet capturing, decision analysis, and all of this.
I will talk about it in details in virus bulletin.
Just join us.
That's the website.
The GitHub version.
Join SADF or use it.
You can reach us for exhibition detection system.
If you need to support this idea, if you have a feedback, if you have any question, if you have anything, just email me or send me on Twitter or anything.
That's it.
It is exhibition detection system.
In my opinion, it's a new era.
Just all people should jump to something like this.
That's the new technology that can stop the ABT attacks.
Join us.
Thank you.