Hi.
Welcome to this INE video lesson on Privileged Access
Workstation.
The agenda for this video is as follows.
First, we'll look into the problem
and why is it that we need privileged access workstations.
Then we'll discuss what privileged access
workstation is, go through some of the core concepts behind it.
And finally, we'll finish with a demonstration
in our environment of a privileged access workstation
so we can showcase what difference a PAW creates
in our environment.
Now, what is the problem?
The real problem here is the risk
that an attacker could compromise a workstation of one
of our administrators.
And by using keylogging or credential dumping,
the attacker might be able to get the privileged credentials
of the administrator running on that workstation.
And in this case, this workstation
is the one that our administrator
is using for their daily operations, reading emails,
for browsing internet.
They tend to have only one device for all their purposes,
including for administrative tasks.
And of course, we don't want this
to happen because in real life this would be game over for us
if this machine gets compromised simply
because if this administrator, who type their domain admin
credentials while performing RDP or any kind of other connection
to a server or a privileged machine,
these credentials might be stolen.
And again, that would just be game over for us
because our entire environment would be compromised.
Then we bring the concept of privileged access workstation.
This is a dedicated workstation that is only
used for administrative tasks.
And this workstation is really security hardened feature
and functionality locked-down.
It will have very limited functionality that
is available to it simply because everything that is not
available is going to be disabled by default.
By doing this, by really having this separate machine
and security hardening it, we are protecting
against the phishing against our administrators
and that will also protect us against credential theft
attacks, Pass-the-Hash.
We're protecting privileged credentials
in a separate machine and as you're
going to see later in our demonstration,
this separate machine is going to be so locked-down that we'll
limit the ability of anyone ever essentially compromising
this machine remotely.
Now, PAW creates a trusted environment as you may say
and having one PAW per user is not necessary,
at least we don't have to map users to our PAWs.
Because the PAW machine is a trusted workstation,
multiple users can use the same machine to perform actions.
With that being said, if you have people who are on call
or working remotely then in those cases, of course,
they need to have one machine with them.
But in a shared office environment
you also have the opportunity to share one
machine with multiple users.
Of course, having a separate machine per user
is going to be preferred probably
by the users themselves as well.
The implementation can consist of multiple variations.
I've seen quite a few and the reason
why there's multiple variations is simply
because we're introducing a separate machine
to our administrators and that tends to drive them crazy.
They're saying, having to bring another laptop with me
all the time, that's a no-go.
This is by far the best option we have,
to have a separate physical machine.
But in case this is not a solution in your environment,
another option would be to use virtualization on your machine.
But the caveat is that the host machine has
to be the privileged access workstation
or the virtual machine will be the one that
is being used for the operations' emails, internet,
and basically whatever else the administrator needs that is not
an administrative task.
So the host is going to be a hardened locked-down machine,
a PAW and the virtual machine or virtual machines running
on it will be acting as their day-to-day operation laptops.
This is preferred by some users and not so much by others
because they're, again, starting to get
annoyed by having to operate in virtual environments
on their daily tasks.
And I've also seen some alternatives
to implementing this, they're not really
recommended compared to the separate physical machine
but it's also an option of how we can go forward and implement
this.
One of the most common scenarios I've seen being pushed out
is a jump host or the concept of jump host
but the jump host itself is acting
and it's locked-down as if it was an actual power machine.
So you will lock down that server
that only one type of incoming connection is allowed
and that incoming connection will require a second factor
for authentication.
So if we take for an example a Windows
server we can block all incoming connections except RDP
and then require multi-factor authentication with the RDP
logging.
So username and password is not enough alone
to get into the jump host.
And in the number one implementation,
administrators will use their day-to-day operation
workstation to connect to jump host
but they'll have a jump host on their accounts.
An account which is only for locked-down specific jump host,
username and password and multi-factor authentication
required in the connection.
Once they're connected to that jump host then
they'll have the ability to perform a new RDP
connection from that jump host to connect to tier-0 systems.
And if you think about this concept,
the privileged credentials are isolated with the jump
off itself, they never touch the unprivileged workstation
that the initial connection originates from.
So what we really want to achieve with the PAW
is having these two channels where
the administrator on their daily tasks
will have their user channel, a separate channel that
doesn't interfere in any way with administrative tasks,
and then a whole separate channel
for administrative tasks that does interfere
with user interactions.
So any potential exploitation of vulnerabilities
that could come from a user concept,
they would be mitigated by having
this separate administrative channel.
Now, what we would normally recommend for PAW
hardening is you should take security hardening guidelines
such as the ones from the Sys or the Microsoft security
guidelines, but normally I recommend the Sys ones
because they're way more complete compared
to the Microsoft ones but the Microsoft can
be a starting point as well.
But some of the features such as LAPS, really lock-down host
firewall, Bitlocker, Credential Guard, Windows Defender
Application Control.
Actual strict application whitelisting
is really necessary on these machines because on a PAW
the only thing you'll be doing is performing an RDP connection
or running one specific tool that you need to connect
to your remote machines.
So creating a complete lock-down whitelisting solution
is more than realistic.
And finally we need to manage the user right assignments, now
PAW, who have access to logging that PAW physically, who
have access to login to that PAW remotely, and so on.
And really no one should need to have the ability
to log into a PAW remotely.
It should only be allowed physically.
Let's go to the environment and have
a look at a sample implementation
of a privileged access workstation.
I'm now connected to our domain controller
where I have the probably familiar to you already,
this tiering structure in our environment.
And in the PAW organizational unit I have created some GPOs.
If we go into the same organizational units
in [? existing ?] computers we'll
see that there is now a workstation called PAW01.
So all the GPOs that we have linked in here
will be applied to that PAW machine.
Now looking at the GPOs many of them
are the standard Sys hardening guidelines.
I have simply split them into multiple organizational units
because it's much easier for me to debug if something breaks,
by having them in separate containers.
And while the default ones are not really interesting
because they're just coming up from the recommendations
from Sys, what I want to spend time on is two of these GPOs.
The first one is the IPsec RDP, the firewall
and the user rights assignment.
I will start by looking at the user rights assignment.
What I want to outline here is my implementation
of who can access this machine.
So if we look at who can log into the machine,
we'll see that a group, PAW users,
and the built-in administrators' groups
are only allowed to log into this machine.
At the same time, denied access on this computer
from the network, we're basically
denying access to all privileged users in our environment.
So no privileged user can access this machine remotely and also
locally as you'll see further on in this implementation.
So the only real way to login to our workstation
will be to be a PAW user or be a member of PAW users
and log on to this machine locally.
Now, this is very important because we
are limiting who can access our machine
and by doing so we are limiting the potential risk
of credentials being compromised,
and then our PAW being compromised remotely.
Which brings us to the firewall.
The firewall is really strict.
I will just go inside the GPO because showing the firewall
rules in theory is much easier and more comprehensive.
The firewall rules are in Windows Defender Firewall
with Advanced Security.
I will expand the window and then select the firewall
itself.
Let's begin by first looking at the firewall properties.
As you can already see in here, we
have enabled the firewall on all profiles
and what is interesting is that we're
blocking both inbound and outbound connections that
do not match a rule.
So unless a specific explicit rule exists,
connection is going to be blocked.
Now, if we're looking at the rules,
let's start by looking into inbound rules.
So these are the very few rules that we're
going to introduce in our environment
and the core ones really are the ones that
are associated with DHCP, so when
we connect our machine to the network
it will be able to obtain an IP address.
Again, this is very important because we
are limiting the attack surface to our machine.
And what is even more is that we are explicitly
denying ports which will allow for remote code execution
from being accessed.
So even if someone had an account
to connect to our PAW machine remotely,
we're simply blocking that connection
from occurring because we're not allowing BMI SMB or PowerShell
remoting connections to our machine
and we certainly don't allow RDP either
since that rule doesn't exist.
If we go into the outbound rules,
we will allow certain connections to go out.
But again, this is very limited.
What you're going to see is that this machine will not
have internet access at all, unless we
allow a specific machines to be accessed on that internet port.
We are really allowing that our machine should have access
to certificate authorities, the domain controllers.
It needs to have access to our VPN IP address
in case we're connecting someone from outside,
and the very core needs for this machine that might be required.
You might also require to have a rule which allows connection
to a SIM system so the administrators can go and look
at alerts on that SIM system by using their PAWs.
But again this is a very limited core set of rules
that we have in here.
And this is the only outbound connections
which we are allowing from our PAW machine.
Now, other than that, you'll see that we actually
allow unrestricted outbound RDP connection.
So from our PAW machine you can perform unrestricted RDP
connections.
And that's really the purpose of having the PAW
machine because you want to manage your servers remotely
from here, and in this case that would be [? our ?] RDP
but you can use any other tool that you might desire instead.
The final GPO which I want to discuss is the IPsec RDP one.
The purpose of this GPO is to use
IPsec to establish a secure channel between the PAW
machine and our tier-0 systems.
And by doing so we can perform Kerberos authentication,
such that our remote servers are only
going to allow RDP connections if they
come from our PAW machines.
And to demonstrate this, I have the policy also
created on our domain controllers, which will only
allow incoming connections if they originate from this PAW
machine.
And I can show you how the configuration for allowing this
is created.
It is, again, the Windows host firewall.
And this is one of those hidden features of the host firewall
which is really, really nice.
So if I look at allowed incoming connections,
I will see that we're not going to allow incoming connections
unless they are explicitly allowed in here
and we also specify the remote connections
which will be given the opportunity to connect
if they have authenticated.
In this case, the only machine which
we allowed to perform this RDP connection on port 3389
is the machine called PAW01.
So let's see how this works in reality.
I will go to my PAW machine, which is just here.
Then I will attempt to perform a remote connection to our domain
controller.
First connect, it might take about 10 seconds for the IPsec
to get established and then I'll get prompted to authenticate
with any user that they want.
And in this case, I'll use a tier-0 account
if I wanted to connect to a tier-0 system
such as the main controllers, and this is how it works.
Now, if I look at a non-PAW machine, for example,
this server, I have server 01 and if I try to perform
the same RDP connection from the server,
this connection will just hang and in about 30 seconds
or so it's going to error out because this machine is not
allowed to perform this type of remote connections.
And in this case, we have allowed this one for RDP
but it can also be configured for any other protocols.
Here we can see error that the server is not
allowed to connect.
The PAW machine also has something
that is interesting in the user right assignment
GPO, which is defining the administrators of the PAW
machine.
We again, since we're not allowing
domain names or any privileged user
to be allowed to log in to PAW, we
need to have different means of managing it.
And what I've shown in here is that I have created a separate
group called PAW admins and whoever is a member of this
group cannot be a member of any of our other privileged groups
because the other groups are denied access to the PAW.
So this PAW admin account will be only an account
that is used on a PAW.
And this group is going to be added automatically
to the built-in administrator's account
and whoever is a member of this group
will be an administrator on the PAW.
It's important to note that the users who use the PAW machine
are not administrators on this machine.
Administration on this machine should only
be required if necessary by a personnel that has the ability
and understanding of the issues that they may create
by changing the configuration.
Let's just simply list the administrators on this machine.
And what we're going to see is that those
are the group which we just mentioned,
PAW admins, which come from the GPO and the account
administrator.
The account administrator is always added by default and we
cannot remove it from the group policy object but it's not bad
to have this account as a way in to get into the machine.
And usually this account is going
to be managed by a tool such as LAPS
so the password is going to be unique for each machine
and only domain administrators will
have the ability to obtain it.
I hope that this video gave you a good introduction of what
a PAW machine is and the purpose of it.
But the real idea is to lock it down and only
use it for administrative tasks in our environment.