[Autogenerated] the original protected processes model was
limited to this DRM protection aspect.
However,
in Windows 8.1 Microsoft decided to enhance the protected process
model into something called protected processes,
slide or PPL and this was extended for two very important aspect.
One of them is the fact that there were several supported levels of protection.
So not all protected processes are now the same.
Some processes are more protected than others,
meaning that a more protected process has full
access to a less protected process, but of course not vice versa.
And the second thing that was allowed is now to have third-party anti
malware executable is usually using what services are also eligible to be
signed by Microsoft and running as protected.
And this was important in order to protect these processes from
malicious actors that might disable them.
So in a very kind of simplistic way,
the way most anti Moreau solutions work is that
they have at least two components.
One of them is usually a kernel driver.
Its purpose is to get details about things happening in the system,
such as getting process and thread notifications when
processes gets created or destroyed and so on,
and then it usually passes that information to a user mode service that does
the actual decision making and perform some kind of logic to try to figure
out whether this activity is malicious or not.
And so if you have some malware infiltrating the system and
manages to get some privileges of an administrator.
It can, it can stop the service or even terminate the service,
which essentially renders the anti malware solution as completely
dead in the water because the fact that we have a driver that still
runs and continues to gather information is useless if nobody is
acting on that information.
So now it is possible to sign anti malware services as protected as well.
Also as a nice bonus,
many of the system processes are PPL protected since Windows 8.1
processes such as the SMS s the session manager.
CSR assess the Windows subsystem process,
services which is the service control manager,
we need it and some others that are protected kind of out of the box,
which makes it much more difficult to infiltrate those and terminate
them because they are also protected from termination.
So what are levels supported there in terms of PPL Microsoft
defined these eight levels where level zero essentially means
unprotected the first level,
which is known as wind system is applied to the most
important processes in the system.
This is the system process itself which is protected in
this way and also minimal processes we'll discuss in the
coming uh part in this module.
The next level is called Wind TCB.
TCB is short for trusted computer base,
which means that we're talking about components here which are
essential to the Windows operating system.
They are typically critical processes such as C S r S S S S s.
These are supposed to be signed with level six and then we have
level five which is a bit less powerful for various Windows
components that are handling sensitive data.
One of them is the Windows defender advanced threat protection
product that is available for enterprises.
And then we have Elsa's and so Elsa's is a very well kind of
well known processing windows that is used for authentication
once it authenticates a user,
it stores a blob of data that represents that authentication.
And so that blob of data can be used to authenticate
automatically on other machines in the domain.
And in the past it was use using something called pass
the hash or pass the ticket attack,
which essentially means that someone managed to grab that blob from
Elsa's address space and then just use it to automatically log in to
other machines in the domain as that user.
So this is a very dangerous and fair common attack.
At least it was in the past.
And so you might be wondering why is Elsa's not running protected?
If you look at a typical window system,
you'll find that Elsa's is not running protected because it seems
to be a good idea if it would be protected,
that bloke would not be able to be extracted by anyone,
including those running with privileges.
And so the problem is that, well,
first you can make Elsa's run protected by changing
a certain value in the registry,
but by default is not running protected because
protected processes have that limitation.
They can only load DLS signed by Microsoft and it makes sense because if you can
force or persuade some protected process to load your DLL,
then you're in a very good shape.
From a security perspective you can do a lot of things
and you are very well protected.
And because Elsa's can be used to authenticate using custom mechanisms
such as fingerprints or eye retina or other custom ways.
Elsa's is able to load this Dll known as authentication packages and because
authentication packages can be written by any event or not,
just Microsoft,
Elsa's is not running part by default simply as a way to ensure
compatibility with existing and future authentication mechanisms,
but it is possible to change that to run protected.
I can say that in the Windows phone 10 environment when Windows phone existed,
Elsa's was running protected and that's because the
Windows phone devices much more closed or less open to
adding new authentication mechanism.
In fact, Microsoft has full control of that form factor.
So if Elsa's does run protected,
this is the level that it runs at for anti malware.
This is the level used for third parties and we're seeing the next
demo that even Windows defender as being well,
something that Microsoft provides is actually using the same Signer level
as anti malware and this is level number three and this does not allow
termination of these processes from user mode,
no matter what there's some other less interesting um Seiner
levels such as processes that host or generate.
.NET native code and authentic code is like the classic um level to use for
DRM content protection if the the the protected process light model is to be
used and zero just means and no protection at all which is the default for
all non protected processes so you might be wondering what is that level or
where exactly does it appear And just seeing the next demo is going to be
part of the process.
Data structure in the kernel and this is the way to know which process is
more protected than other another process and so on.
If you combine that we get this set of values that are actually stored in the
processed data structure and so we have these two values.
One of them is the final level between zero and seven and then
there's the protected or protected light model.
So the protected model is still there, it's not going away.
And for protected the value is two and for protected light the value of one.
If you combine those you get some number and the higher the
number means the higher the protection,
the more powerful the process and as I mentioned earlier,
a more protected process can fully act less
protected process but not vice versa.
So first one is protected system that's the most powerful one that is used
for the system process and minimal process is another one which is very
common is the protected light in wind TCB level,
which is used by CSR recess and similar processes.
We have the protected light on Windows level,
which is also used for things like the Windows defender
Advanced threat protection product we have for Elsa's that
would be the level to be used by Elsa's.
If it is running protected for anti malware products,
this is the level that's going to be used level number 31 as the
sort of final number of the protection value.
And again, for non protected processes, zero is what's going to be there.
The other levels exist, but they're less often used.
It's time to see that in various tools.