We're going to talk about the concept of the attacks from the client side.
These attacks are more and more common.
This is because network administrators and software developers fortify
the perimeter, and pen testers need to find a way to make the victims
open the door for them to get into the network.
And that's the reality of our testing today.
We need a little bit of help.
So how do we get that help?
Tricking the client.
One of the first things we do is we trick the client.
We need the client to provide us access.
Once they've done that, then we implant whatever payload we want to use.
The next thing we're concerned with is,
once our payload is planted on the machine,
how do we avoid detection.
There are multiple protection factors that are in place,
so we have to figure out a way to try to avoid these.
The reality is there's always a chance that we get detected,
and if we do, more than likely our payload is deleted,
but we still want to understand the process of how
to try to avoid this detection, even if it may not be successful.
And then the last thing we'll look at,
the different types of client exploits and what's
required to use these types of exploits.
We're now ready to talk about that trickery.
How do we trick that client into giving us access?
It all relies on trickery and deceit.
When you think about this, how do we accomplish it?
The most common way is the infamous click here.
We want their clicking to give us the access we need.
The good news is it's not very difficult to achieve.
The human nature of curiosity will make most users click,
and that's why these types of attacks are very successful today.
Our next method is that of opening.
It's the same premise of leaving a box out in the
open to see if anyone will open it,
because we know if we give somebody something that interests them,
they're more than likely going to have that curious nature and want to open it.
And when they go to open it, it's like opening the box.
That's the same concept.
And we do this as a form of deceit.
We're providing something enticing and hoping they open it.
Then this next one has become more and more difficult to achieve,
and that is the running of our code.
We want them to run the code on their machine.
Now, in the early days, this was easy because most users would do what?
click and let things run.
But the operating systems designers have improved,
and now when the potential victim clicks or double‑clicks
they get a nice pop‑up window that comes up,
in many cases, and says this action could be dangerous.
So that's the bad news.
But the good news, all we need is one,
and in most cases we can always find one that will still let our code run.
And that's a win for us as attackers.
If you look at the latest and greatest attacks,
we see that more than 80% of these attacks use email,
and, of course, an email is the phishing lure.
That's how we get people to interact and give us access.
All we have to do is get them to open that email,
and once they open that email,
fall for whatever trick or deceit we have in the email,
that's how we're going to get access.
And remember, once again, all we need is one,
and that's why the actual phishing campaigns continue to this day.
And what are we doing when we do that?
We're setting up some form of a connection for a command and control so we
can exfiltrate different components and artifacts of data.
These are all these different types of things you want to be aware of.
We have three different types of payloads,
and think of a payload as what we want to happen once that user gives us access.
So we'll look at the first one, it's the common ones and zeros, or binary.
It's a program that we're going to use that is in a binary format,
and in that binary format of ones and zeros,
it's usually compiled, and it will be executed.
So we have to get the users just to let that code execute.
So in the modern day, this can be a challenge.
So what we need to do is test it thoroughly before deployment.
And then next we have scripts.
Now scripts are a little bit different because it's still code,
but it's not in a compiled type.
That is, its text or strings that's going to be parsed by an interpreter.
So that interpreter's going to actually parse our line‑by‑line script
and do whatever action the script tells it to do.
It's not a compiled‑into‑binary form, so it could be a Perl script,
a Bash script, all these different types of things.
So all we have to do to get this to run is have the user run
it with an interpreter on the machine.
As long as there's an interpreter on the machine,
be it the Perl, Bash, or even Python.
Now, Python, it will run.
In most cases, Linux will have these interpreters installed by default,
so it's up to the administrator of those systems to remove them.
And that's our advantage.
In most cases,
administrators just install Linux and don't even do any customization,
and that's one of the main things we can do.
So if neither one of those work, the binaries or the scripts,
we can go through the ever‑friendly Trojan.
Remember,
Trojan is a program that looks benign or innocent but has a
nefarious nature to it in some form of evil.
Of course,
the most common way of doing this is to create a Trojan of a
program or utility that's often used by the user.
So when they go to use that utility or that program,
the Trojan itself is run and not the actual utility or program,
and then the Trojan carries with it usually some form of a payload,
maybe a shell, a keystroke logger.
Some of these are different examples.
You're probably wondering how in the world do we accomplish this?
Well, we accomplish it with a tool, and that tool is msf,
for Metasploit Framework, venom.
So when you look at it, what's this tool going to do?
It's going to generate our payloads, extremely powerful tool.
Gives the capability to do many different things on the machine.
The only limit is our imagination.
So it gives us these different outputs that we can custom and
tailored for any of the environments we might encounter.
Remember, that's our goal here.
If we know we need a certain type of payload,
we've got to generate that payload to have a better chance of success.
We do that with a tool like msfvenom.
So we do our research and see, from discovery and all the other components,
what does and does not work against the client‑side operating
system and the defenses that are typically in place.
And then we build a payload to provide us the access to that client system.
And now we are ready for a demo.
In this demo,
we will look at the review of the different payloads and at
the process of building our own payloads.
Enjoy the demo.