- Up next on Microsoft Mechanics,
I'm joined once again by hacker-in-chief
and Windows security expert, Dave Weston,
to go deep on Windows 11 security
and the rationale behind hardware requirements
for implementing the highest default security baseline
to date, and how this provides significantly
more protection against today's most sophisticated malware
and attacks.
So Dave, you famously founded the Red Team
of professional hackers at Microsoft,
and it's really your team's job
to stay ahead of external threats
that might compromise Windows.
So the new system requirements
with Windows 11 were a surprise, I think, to many of us.
Now those balance performance, reliability,
as well as security.
- They do.
The approach we've taken is an evolution
of what we've been doing for a while.
Many of the optional or high-end security controls
from Windows 10 are now on by default and required
on new machines shipping with Windows 11.
This is critical because cyber attacks
are at all time high
and getting more and more sophisticated.
So things have really shifted from attacking
for bragging rights to big business,
and enough's enough, really.
A lot of what you're seeing in Windows 11
is what we defined as a secured-core PC back in 2019
with our then-new device security requirements
to protect against targeted firmware attacks.
And this outlined a number of new protections
against modern threats.
It has the Zero Trust security model baked in
with layered security,
from the silicon on the board itself,
to the actual boot process, your login as a user,
and the apps that you use in your Windows session every day.
- And one of my favorite parts of having you on the show
is making all of this real and showing the attacks
in action for real, and also how you would stop them
in the new version of Windows.
- Today I have a few different attacks
I'll walk you through,
and we'll start by showing them succeeding,
then I'll break down each protection
that we put in place to stop them,
and then I'll prove to you that they all work.
For the first one, I'm going to demonstrate an attack
on a Windows 10 machine without a TPM
or Secure Boot enabled.
I'll start by getting into the process
that a hacker would take.
There's a website here called Shodan.io
that people use to identify vulnerable machines
connected to the internet.
Things like web-facing RDP ports,
such as 3389, that are open, etc.
If you don't know about this site,
it's actually a really good idea
to check it out and see if your organization is exposed.
A lot of people have turned to RDP to enable
remote work in the last year, I know I have.
Of course, this can always be secured and locked down,
but I'm going to show you the potential consequences
if that hasn't been done.
So here, let's start by going to Shodan.io
and I'll search for Fabrikam as an organization
with port 3389 in the US.
And I can see that the Fabrikam domain is in fact
a machine online with an open RDP port.
So we can even see with the thumbnail of the login,
which specific usernames have console access.
So now I'm going to switch over to my Kali Linux terminal
that I pulled down from the Microsoft store
and is running on Windows Subsystem for Linux.
So now I'm going to try to brute force log in
to this VM in the cloud,
I'm going to try to brute force it
with a tool used for pen testing
from the Kali Linux distro.
So I'll actually run it, the tool,
with a password file that has the most common passwords
that we've seen from leaked databases
or ones that you might've seen
on sites like haveibeenpwnd.com.
This one just uses the most common passwords,
but there are sites like dehashed.com
where you can search for a specific text stream
for domain or email accounts and increase your efficiency
on brute forcing.
Anytime you're brute forcing,
it can take between minutes, hours, or days,
and that's going to fully depend on the configuration,
if there's a lock-out policy and password complexity,
but because this is a simulation, just to save time,
I'll let it run for a few seconds.
So now I'm running it and we can see right here
that there's my password in plain text,
and there's an admin account along with the username and IP.
So if I just go ahead and plug these in to the RDP client,
I've already set the IP, I've set the username,
and of course I'm running this super high-resolution laptop,
so let's make sure we can see everything,
and now I'll input the password that we just brute forced.
And that's it.
Now it connects and you can see that I'm the admin
on this machine and I can pretty much do
whatever I want now, I'm in full control of it.
- I gotta say, it's really crazy seeing how many machines
are just on the site;
all the details about the login user accounts,
with RDP open to the web.
- What's even crazier is that I'm in a physical machine
that was open to the internet.
RDP is one of the most common attack vectors for ransomware,
and it's also still running old school Master Boot Record
or MBR, no UEFI.
There's a TPM there, but it's disabled.
So let's just look at how vulnerable this machine is.
So an easy way to do that is to pull up MSINFO.
And now I have it open here.
You can see that the BIOS mode is actually in legacy,
which means secure boot is unsupported.
Now I can actually make any of the modifications I want
with full elevation, as the machine admin.
So for example, if I want to install a rootkit or a bootkit
to undermine the system, I can.
In fact, I've opened the prompt as an administrator here,
and I've stored an EXE on my desktop.
I'll change directories there,
and then I'll run this tool
I've created called MBRrewritetool.exe.
This has a malicious payload, it'll make changes directly
to this legacy boot record.
So I'll just type in yes,
and then the program initiates an immediate shutdown.
Just give that a second.
So now Jeremy, why don't you go ahead
and reboot your machine to see what happens?
- Hold on. You did that to my machine?
I wasn't even looking, it's shut down.
Okay. So, I'm going to turn on my PC in this case.
So let me go ahead and power it up.
It looks like PXE is still working,
that's a good thing just in case all else goes wrong.
And it looks like there's some ASCI art there,
and it looks like you want me to pay you.
- I do. Pay up, Jeremy.
So as it says, you need to pay up,
and you've got to send me some cryptocurrency
and then I'll fix your machine up for you.
- All right, I'll get right on that.
As we all know, by the way,
rewriting the master boot record, it's pretty bad.
Even if you can boot into WinPE or WinRE and try to fix it,
there's no guarantee that the primary partition
is still recoverable.
- That's right.
And this is similar to the NotPetya attack
you might've seen a few years ago.
I could have easily encrypted your hard drive,
and I'll show you in just a second
how this is addressed with Windows 11 default protections.
But for now, let me show you another cool attack.
This time it's going to be related to biometric log on.
So I'm on a machine without virtualization-based security
or enhanced sign-in security turned on.
So let me log in here.
I'm going to try my finger.
And because this isn't my PC,
you'll see that my fingerprint didn't work to let me log in.
This is fully expected.
Now for the next part of the demo,
we've actually fully disabled virtualization-based security
on this machine, and even though VBS is on by default
for new machines running Windows 11,
I also have a direct memory access device here
called a PCI leech.
And I'm going to use this to access what's in memory
on this victim machine, from my attacker machine
and I'm going to use that to modify
the biometric authentication code for fingerprints.
So I'm actually going to connect over Thunderbolt,
just make sure that's all plugged in here.
And once I do that,
I'm going to run an exploit that allows me to modify
the authentication code.
So here on my other machine, code named Gambino,
I'll run \dma_unlock.exe.
And that'll just take a second
and you'll see that there's a patch written
to the biometric code, which was fully successful.
Now, I'll try to log in again.
This time I could use my finger,
but why don't we do something cooler?
(paper rustling)
So I have got one of my favorite things here,
a pack of gummy bears.
So I'm actually just going to open this up.
And first things first, I'm going to have a gummy bear
to power up a bit, and then I'm going to take
this red gummy bear,
and I'm going to try to log in with it.
So this should work with any capacitive object.
I'm a gummy bear fan, so I'm going to try that.
So we're going to go ahead and just rub that on here.
And voila!
You can see that we can log in with a gummy bear
and that since this account is a local admin,
I'm back in control of it.
I can do whatever I want with this machine, I fully own it.
So I've shown both a remote attack,
as well as an in-person physical attack,
and both of these have better protections in Windows 11.
- Okay, so what can we do then in Windows 11
to stop these types of attacks,
and what technologies then come into play?
- So we'll start with the attack we just saw,
and after that, I'll fix up the attack
where I modified your MBR.
Because the fingerprint authentication hack
was against memory,
this is where virtualization-based security or VBS comes in.
So if you think about the DMA device here,
which allowed me to bypass the biometrics,
it actually needs to modify system files in memory
to work over its Thunderbolt connection.
With VBS enabled this can't happen, because VBS separates
the things we really need to protect
from the running OS session.
Things like encryption keys, signatures, and code,
are locked down in an isolated region of memory
that's completely separated by hardware
from the operating system.
So here, hypervisor-enforced code integrity, or HVCI,
manages code integrity policy enforcement.
It'll check signatures of drivers or system files,
and when signatures don't match,
they won't get loaded into system memory
and most importantly,
you cannot modify code that runs into VBS enclave.
So first, let me show you how to enable
enhanced sign-in security for Biometrics.
I'm in a PowerShell ISE here, and I'm going to add
this reg key to my device guard settings,
under scenarios and secure biometrics.
Now I'll query the key just to make sure it's enabled
and see if it looks good.
For the setting to take, I need to reboot the machine.
So since I'm already in PowerShell,
I'm just going to run a shutdown command.
And now I just to need to wait a second for this reboot.
And once I'm back in Windows, I'll open up PowerShell again,
and make sure our key is enabled.
Okay, so there's my registry query,
I'll re-run it, and it's still on.
And importantly, it was on during the reboot,
so that stayed on.
So now let me just pop into the start menu
and I'll hop into the event viewer.
Now I just need to find the Biometric events.
So I'll jump in the application and services logs,
now Microsoft and Windows,
cue the Jeopardy music.
I just need to find Biometrics.
And now in operations, I can see there's a couple of events,
and I'll click the first verbose one.
So you can see from this event data
that my fingerprint sensor is now fully isolated
in a virtual secure mode process.
It wasn't before I changed the registry key and rebooted,
but now it is.
So I'll just go ahead and minimize the event viewer.
I'll open start again.
And I'll go back to our handy dandy MSINFO.
And with MSINFO, you'll see that
virtualization-based security is actually now running
on this machine, which is great.
So now I'll just lock this machine with Windows L
and I'm going to try the same attack again.
So I'll get my DMA device hooked up, my PCI leech.
So now that that's hooked up,
we will try to run the DMA unlock.
So, go here, run that again.
And you'll see that this now fails
with a memory access violation while it was trying
to patch the DLL, because that DLL is now running
in a fully-protected, segmented area of memory.
And just to prove it, I won't do the gummy bear this time,
but I'm going to try to log in with my actual finger.
It'll actually prompt me to use the fingerprint,
and you can see it's blocked.
- Okay, so this in this case, uses a secure enclave
and memory to block any code modification,
but, is there anything else going on then under the covers?
- Yeah, the protections go all the way down
to the silicon level.
Once the enhanced sign-in security is enabled,
the key that is used in lieu of your password
is actually stored in the TPM or Trusted Platform Module.
If you're not familiar with TPMs,
these are physical or virtual chips
that are on your PC's motherboard or in the processor.
Their purpose is to protect encryption keys,
user credentials, and other sensitive data
behind a hardware barrier, so that malware and attackers
can't access or tamper with that data.
With Windows 11, we're requiring TPM 2.0 on new installs
by default.
Most computers built over the last five years
come with this, sometimes the TPM chip
has been turned off in the firmware
and it'll just need you to enable it in your firmware bios
to get the protections from it and install Windows 11.
- And by the way, one tip here,
the TPM chip on your firmware,
it can be also referred to as, IPTT on an Intel system,
or fTPM on PCs with AMD chipsets.
So, why don't we move back to my machine here,
it's bricked right now, it's in ransomed state.
So, how would Windows 11 protect something like this?
- Sorry about that, Jeremy,
but it was for a good cause I assure you.
So this is where UEFI, Secure Boot and Trusted Boot come in.
I'm not going to cover the ways
to make my initial remote attack vector
over RDP more secure.
That would be a great future Mechanics.
But if a machine is compromised,
we can help you minimize the damage.
Windows 11 will stop these type of attacks
out-of-the-box because we're using Secure Boot
and Trusted Boot, which use both
the required UEFI and TPM hardware.
Secure Boot and Trusted Boot stop rootkits or bootkits
that attempt to modify your early boot files.
So Jeremy, why don't you try enabling Secure Boot?
- Sounds good, I want to get this thing fixed.
So, now I'm going to boot into firmware settings
with my F key, and I'm going to go ahead
and enable Secure Boot.
And while I'm in here, I'm going to see that it fails.
And that's by design, by the way, don't worry about that.
That's intentional, because for Secure Boot to work,
I actually need to disable legacy ROM options in this case.
So now I can enable Secure Boot.
Once I've done that and hit Apply,
and this system now requires that it's booted
with UEFI and also Secure Boot in order to work.
So, now that I have UEFI and Secure Boot
and Trusted Boot enabled,
how exactly does that protect my machine
from future attacks?
- So UEFI by itself actually adds more security
to the boot sequence.
Rootkit and bootkit attacks typically try to inject
malicious code very early in the boot sequence
so they can run undetected
before your protection software loads up.
UEFI has security baked in the initial phases
of the boot process, and it works hand-in-hand
with our boot validation processes from Windows
to stop rootkits and bootkits.
When you boot a system before handing off to the OS,
Secure Boot then checks the boot loader's digital signature
against keys configured by your OEM
to make sure it hasn't been modified.
Then Trusted Boot takes over to check the kernel
and other boot-critical components
and record the information to the TPM
that is used by measured boot.
The TPM stores audit logs when using measured boot
that can be measured against known healthy boot logs
on a local server, or even against the Intune service
for Zero Trust scenarios.
And if everything checks out, Windows will boot.
If not, we'll catch it and either enforce it
with things like conditional access,
or we'll put the machine into BitLocker recovery
and you can recover that the next time you boot.
- Okay, so now we know how it works under the covers,
but can you prove here in this case that it works?
- Sure.
So I'm in Windows 11.
I'm logged in as a local administrator.
So my PowerShell script here is going to attempt
to copy in a new EFI boot file
to the S:\ drive I've just mounted.
Then I'm going to write the Bootmgr in order
to boot into a ransomware environment,
which has that beautiful piece of ASCI art
and payment request you saw on Jeremy's machine earlier.
But now because I have Secure Boot
and Trusted Boot enabled, this won't matter
and the attack will be defeated.
So I'm going to restart this Windows 11 machine
with those files in place.
And under the covers, it's going to reject the changes
that were made to the boot files.
It's going to take me to the normal login for Windows 11.
So the threat was automatically neutralized
as part of the Secure Boot and Trusted Boot processes.
- Cool, so that really helps explain the TPM
and virtualization-based security,
UEFI and Secure Boot requirements,
but did those capabilities also play a role
into the system requirements for the newer Intel
and AMD Ryzen chipsets?
- They do.
So while earlier processors might've supported VBS
and HVCI for the best experience,
the newer processors have much better performance
running the required virtualization.
- And that makes a lot of sense.
You know, we need all the security we can get,
but we don't want that at the cost of lowering performance.
And these attacks really show what TPMs
and virtualization-based security really bring to the table.
So, how do you recommend people learn more about this
and get started with these protections?
- First, try Windows 11 now in preview and upgrade
to it once it hits general availability.
Next, all the protections I showed today
are optional capabilities in Windows 10.
So just turn them on to get better security.
And for any new devices you're buying,
seriously look at our secured-core PCs
from a vast number of OEMs.
They have the most built-in protection
and there'll be ready for Windows 11
once you're ready to upgrade.
- All right, and there's one more related tip.
You know, if your PC meets the requirements for Windows 11
and is currently using a BIOS and Master Boot record
or MBR partitioning,
you can switch from MBR to GPT partitioning
that's needed for UEFI without reformatting your disk
or reinstalling Windows from scratch.
So just check out our show at aka.ms/MechanicsMBR2GPT
to see how to do that.
So, thank you so much Dave,
also for answering all of our questions
and for that insider's perspective
into Windows 11 hardware requirements.
And be sure to keep watching Microsoft Mechanics
for all the latest updates.
Subscribe to our channel if you haven't already,
and as always, thanks so much for watching.
(upbeat music)