-
Notifications
You must be signed in to change notification settings - Fork 0
/
CredentialGuard.html
1090 lines (1052 loc) · 51.4 KB
/
CredentialGuard.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>
I want to run Credential Guard in virtual machines
</title>
<link rel="stylesheet"
href="Style.css" />
<link rel="shortcut icon"
href="favicon.png"
type="image/png" />
</head>
<body>
<h1 id="top">I want to run Credential Guard in virtual machines</h1>
<p>
version 2019-08-31 by <a href="/">Artem Pronichkin</a><br />
submit a
<a href="https://github.com/pronichkin/pronichkin.github.io/issues">
comment
</a> (“issue”) or
<a href="https://github.com/pronichkin/pronichkin.github.io/blob/master/CredentialGuard.html">
edit
</a>
</p>
<h3>TL;DR</h3>
<p>Good for you. You actually don't have to do anything.</p>
<p>
You know, we at Microsoft take security very seriously. We want the
important security features (such as Credential Guard) to be used by
everyone. And we know very well that if special configuration is required
to enable some feature, nobody will end up using it. So we worked hard
to make sure Credential Guard works in Virtual Machines <i>
in default
configuration.
</i>
</p>
<p>
Read this again. You do not need to change any settings. Whoever told you
have to run <i>ABC command</i> or enable <i>XYZ feature</i> was wrong.
Please see below for popular myths and
misconceptions
</p>
<div style="text-align:center">
<blockquote class="twitter-tweet">
<p lang="en" dir="ltr">
You need to enable Nested Virtualization
(“ExposeVirtualizationExtensions”) in order to have
Credential Guard running inside a VM.
</p>
— Artem Pronichkin (@pronichkin)
<a href="https://twitter.com/pronichkin/status/1167477209034088449?ref_src=twsrc%5Etfw">August 30, 2019</a>
</blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<p>Honestly, I cannot believe how popular this myth still is!</p>
<h3>Wait, I run VMware vSphere/KVM/XEN/etc.</h3>
<p>
Ouch! Sorry, I cannot help you there. You need to talk to the respective
virtualization solution vendor. I might provide some links later, but your
favorite search engine might serve you even better.
</p>
<p>
This functionality might be available—however, it may indeed
require some special configuration. Moreover, you might need to
reevaluate the security promise or goals of implementing this as
part of end-to-end solution, especially if you consider not only
in-guest attacks, but also host-based attacks. (See below for some
examples of such thinking.)
</p>
<p>
Everything below is applicable to Hyper-V, running on a modern version of
either Windows Server or Windows 10. If you are uncertain about
availability of specific feature, please consult official product
documentation or an in-depth blog post. This page is not intended to
replace or substitute any of existing documentation. It can only provide
an additional angle to look at the problem.
</p>
<h2 id="Contents">Contents</h2>
<ul>
<li>
<a href="#1. Basic">1. Some basics</a>
<ul>
<li><a href="#1.1. Credential Guard">1.1. Credential Guard</a></li>
<li><a href="#1.2. VSM">1.2. Virtual Secure Mode (VSM)</a></li>
<li><a href="#1.3. Others">1.3. Other technologies</a></li>
<li><a href="#1.4. VBS">1.4. What about Virtualization-Based Security (VBS)?</a></li>
</ul>
</li>
<li>
<a href="#2. Myth">2. Myths and Misconceptions</a>
<ul>
<li><a href="#2.1. IUM">2.1. I need to enable the “Isolated user mode” feature</a></li>
<li><a href="#2.2. Hypervisor">2.2. I need to install hypervisor inside virtual machine</a></li>
<li><a href="#2.3. Nested">2.3. I need to enable Nested Virtualization for a virtual machine</a></li>
<li><a href="#2.4. Extension">2.4. I need to configure VM to “Expose Virtualization Extensions”</a></li>
<li><a href="#2.5. Dynamic">2.5. I need to disable Dynamic Memory</a></li>
<li><a href="#2.6. DMA">2.6. I need to disable DMA protection</a></li>
<li><a href="#2.7. TPM">2.7. I need to enable virtual TPM</a></li>
<li><a href="#2.8. Shielded">2.8. I need Shielded Virtual Machine</a></li>
<li><a href="#2.9. Encryption">2.9. I need Encryption-supported virtual machine</a></li>
</ul>
</li>
<li>
<a href="#3. Truth">3. What you actually need</a>
<ul>
<li><a href="#3.1. Secure">3.1. UEFI Secure Boot</a></li>
<li><a href="#3.2. Generation">3.2. Generation 2 Virtual Machine</a></li>
<li><a href="#3.3. Guest VSM">3.3. Guest Virtual Secure Mode (Guest VSM)</a></li>
<li><a href="#3.4. Enable">3.4. Enable Credential Guard</a></li>
</ul>
</li>
</ul>
<hr />
<h2 id="1. Basic">1. Some basics</h2>
<p>
Before diving into details, we need to make sure we're on the same
page.
</p>
<h3 id="1.1. Credential Guard">1.1. Credential Guard</h3>
<p>
We're primarily talking about Credential Guard here because that's
what everyone seems to be obsessed with. Everyone have read about
Mimikatz (or seen some cool demo) and believe they need Credential Guard.
Well, who am I to disagree. However, out of this need, people seem to
drive all sorts of false assumptions and unnecessary requirements. This
becomes particularly noticeable when we start talking about virtual
machines. Nowadays it seems that pretty much everyone have finally
understood the prerequisites to run Credential Guard on bare metal (that
is, on physical computers.) But when we add virtualization to the picture,
everyone suddenly becomes utterly confused. So, we're here to debunk
at least some of that confusion.
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="1.2. VSM">1.2. Virtual Secure Mode (VSM)</h3>
<p>
That's the actual technology that powers Credential Guard. Credential
Guard fully depends on Virtual Secure Mode. The very problem of
understanding and satisfying the requirements of Credential Guard (be it
on a physical or virtual machine) is actually the problem of understanding
and satisfying the requirements of running Virtual Secure Mode. Throughout
this document, we keep saying “Credential Guard” because
that's what everyone is concerned about (and we understand that's
the end goal.) However, what we are actually talking about is enabling
Virtual Secure Mode.
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="1.3. Others">1.3. Other technologies</h3>
<p>
In fact, there is a bunch of other security technologies in Windows that
are independent from Credential Guard but similarly to it depend on
Virtual Secure Mode. For example:
</p>
<ul>
<li>
Windows Defender Application Control (WDAC), also known as Device
Guard Code Integrity;
</li>
<li>
Hypervisor-enforced Code Integrity (HVCI) which is amusingly not the
same as “regular” Code Integrity now known as WDAC;
</li>
<li>
Shielded VMs (they rely on Virtual Secure Mode on the host as
explained <a href="#2.8. Shielded">below</a>)
</li>
<li>
SQL Server Always Encrypted with
<a href="https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-enclaves">
Secure
Enclaves
</a>
</li>
</ul>
<p>
Virtual Secure Mode is designed as an extensible infrastructure, where
additional features can be plugged in as so-called
“<a href="https://docs.microsoft.com/en-us/windows/win32/procthread/isolated-user-mode--ium--processes#trustlets">trustlets</a>”.
Hence, expect more and more features to be
introduced over time with dependencies on Virtual Secure Mode—both
in Windows and other software (such as SQL Server.)
</p>
<p>
All of such features would share the same requirements that are actually
prerequisites to run Virtual Secure Mode. Hence, the below
discussion applies entirely to any of such features. Just replace
“Credential Guard” with the name of the feature you're
concerned about—and keep reading.
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="1.4. VBS">1.4. What about Virtualization-Based Security (VBS)?</h3>
<p>
That's simply another name for Virtual Secure Mode. Exactly the same
thing, just slightly different accent. “Virtual Secure Mode”
(VSM) is a Windows feature name, while “Virtualization-Based
Security” (VBS) is more like a generic industry term. But for the
context of this (and many others) document these terms mean exactly the
same and are completely interchangeable.
</p>
<p>
Do not get confused. We prefer to say “Virtual Secure
Mode” but you can use whatever name you please. Moreover,
“VSM” just sounds less ambiguous than “VBS”.
</p>
<p>
<a href="#top">back to top</a>
</p>
<hr />
<h2 id="2. Myth">2. Myths and Misconceptions</h2>
<h3 id="2.1. IUM">2.1. I need to enable the “Isolated user mode” feature</h3>
<p>
No. That was true very long ago, for early versions of Windows 10. (Namely,
versions 1507 and 1511.) Starting with Windows 10, version 1607, that's
no longer true.
</p>
<p>You might also know version 1607 under one of the following names:</p>
<ul>
<li>Windows 10 Enterprise 2016 LTSC/LTSB</li>
<li>Windows Server 2016</li>
</ul>
<p>
None of these, or later versions of Windows require any optional
features or components to be installed.
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.2. Hypervisor">2.2. I need to install hypervisor inside virtual machine</h3>
<p>
There are multiple hypervisor-related features you might find in
“Windows Features” window (.\OptionalFeatures.exe).
</p>
<blockquote>
<table border="1"
style="border-collapse: collapse; border-spacing: 0; padding:5px;">
<tr>
<th style="padding: 5px">Display Name<br />(used in “Windows Features”)</th>
<th style="padding: 5px">Internal Name<br />(used in DISM or PowerShell)</th>
<th style="padding: 5px">Comment</th>
</tr>
<tr>
<td style="padding: 5px">Hyper-V</td>
<td style="padding: 5px">Microsoft-Hyper-V-All</td>
<td style="padding: 5px">
Parent feature for “Hyper-V Management Tools” and
“Hyper-V Platform”
</td>
</tr>
<tr>
<td style="padding: 5px">Hyper-V Platform</td>
<td style="padding: 5px">Microsoft-Hyper-V</td>
<td style="padding: 5px">
Parent feature for “Hyper-V Hypervisor” and
“Hyper-V Services”
</td>
</tr>
<tr>
<td style="padding: 5px">Hyper-V Hypervisor</td>
<td style="padding: 5px">Microsoft-Hyper-V-Hypervisor</td>
<td style="padding: 5px">
Actual hypervisor, when used as
part of Hyper-V feature, i.e. including management APIs.
</td>
</tr>
<tr>
<td style="padding: 5px">Virtual Machine Platform</td>
<td style="padding: 5px">VirtualMachinePlatform</td>
<td style="padding: 5px">
Hypervisor component without management layer. Required for
non-Hyper-V features like HVSI (not to be confused with HVCI),
Containers, WSL2 or Windows Defender
Application Guard, WDAG (not to be confused with WDAC)
</td>
</tr>
<tr>
<td style="padding: 5px">Windows Hypervisor Platform</td>
<td style="padding: 5px">HypervisorPlatform</td>
<td style="padding: 5px">
Also known as “WHPX”. Allows 3<sup>rd</sup> party
virtualization software (e.g. Qemu, VirtualBox, Android
emulator, and
<a href="https://techcommunity.microsoft.com/t5/Virtualization/VMware-Workstation-and-Hyper-V-Working-Together/ba-p/825831">soon</a>
VMware Workstation) to leverage Windows
hypervisor in place of their own (while maintaining their own
services and management layer), and hence coexist with
other features that depend on it, such as host VSM
</td>
</tr>
<tr>
<td style="padding: 5px">Isolated User Mode</td>
<td style="padding: 5px">IsolatedUserMode</td>
<td style="padding: 5px">
Legacy feature used in older versions of Windows 10
(<a href="#2.1. IUM">see above</a>). Not available
or needed anymore
</td>
</tr>
</table>
</blockquote>
<p>
The funny thing is, all of the above features leverage Windows hypervisor,
one way or another. But this plethora of options and their taxonomy
might be highly confusing—and boy it is! (To make the list shorter
and hence <i>slightly</i> less confusing, the above table does not include
Hyper-V management features. The names of their respective components are
pretty self-explanatory.)
</p>
<p>
Good news, however, is that you do not have to manually enable or configure
<i>any</i> of them! If you see any guidance that tells that you need to
enable any of these features (either manually or via script), that
guidance is significantly outdated. It was authored for some very
old version of Windows which is likely out of support already. If you are
using that version of Windows, you have bigger problems to solve than
enabling Credential Guard. Good luck!
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.3. Nested">
2.3. I need to enable Nested Virtualization
for a virtual machine
</h3>
<p>
That's not true. Nested virtualization is required if you need to run
actual hypervisor inside a virtual machine. As per the previous chapter,
you do not need to run hypervisor if all you need is Credential Guard.
</p>
<p>
Please read this again. You do not need to enable <b>any</b> optional
features inside a virtual machine, or configure <b>any</b> settings
for a virtual machine, if your end goal is to run Credential Guard.
</p>
<p>
(There are other valid scenarios where you indeed have to enable
nested virtualization. These are the scenarios where you need to
install any of the features from the
<a href="#2.2. Hypervisor">above table</a>. For instance, if you
intend to run containers or Windows
Defender Application Guard (WDAG) inside a VM, nested virtualization
is your friend. But those scenarios are specialized and not meant
to be as universal as Credential Guard or HVCI which are designed
to run <i>everywhere.)</i>
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.4. Extension">2.4. I need to configure VM to “Expose Virtualization Extensions”</h3>
<p>
You are talking about this PowerShell command:
</p>
<blockquote style="background-color:blue; color: white; font-family: Consolas,monaco,monospace; padding:15px">
Set-vmProcessor -vm $vm -ExposeVirtualizationExtensions $True
</blockquote>
<p>
This command enables Nested Virtualization. That's exactly what it
does. Nothing less, nothing more. You <b>do not need</b> to do that.
Please check out <a href="#2.3. Nested">the previous section</a>.
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.5. Dynamic">2.5. I need to disable Dynamic Memory</h3>
<p>
This is a known prerequisite to enable Nested Virtualization. While not
strictly required, it's advisable to disable Dynamic Memory if you intend
to use Nested Virtualization. (More details
<a href="https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization#dynamic-memory-and-runtime-memory-resize">here</a>.)
Note that it used to be a <i>strict prerequisite</i> for Nested
Virtualization in some preview builds, but not anymore.
</p>
<p>
However, you are not going to use Nested Virtualization. So, this
recommendation does not apply. If you believe you need Nested
Virtualization please <a href="#2.3. Nested">see above</a>.
</p>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.6. DMA">2.6. I need to disable DMA protection</h3>
<p>
This is yet another known requirement related to Nested Virtualization.
It applies to scenarios where <b>all of the following</b> is true.
</p>
<ul>
<li>You enable Nested Virtualization</li>
<li>You run a hypervisor inside virtual machine</li>
<li>
You <i>also</i> need to run Virtual Secure Mode (VSM) in the same
VM
</li>
</ul>
<p>
As a reminder, there may be <a href="#1.3. Others">
various
reasons
</a> to run VSM inside a VM.
Credential Guard is one of them. However, if you <i>only</i> need
VSM (and any features that depend on it, such as Credential
Guard), you <a href="#2.3. Nested">
do not have to enable Nested
Virtualization
</a>. Hence, this limitation does not apply to you.
</p>
<blockquote style="background-color:lightgrey; padding:15px">
<h4>Fine, but when is it actually needed?</h4>
<p>
The most common scenario where all of the above conditions are valid
is running so-called “Guarded Host” inside a VM, e.g.
for a Shielded VMs lab. Shielded VMs technology (or, more precisely,
virtual TPM functionality) relies on VSM on
the host (and such host is called Guarded Host.) If your host is
actually a VM itself, you end up in this scenario.
</p>
<p>
Another less common use case where the same set of conditions
applies is scenario known as “Repair Garage” used in
some Shielded VMs implementations.
It is different from the abovementioned <i>lab</i> scenario in the
sense that the only Shielded VM is the “Garage” itself.
It runs under a hypervisor which runs directly on bare metal. As
such, we can call it “Level 1” or “Parent”
VM. The “Child” or “Level 2” VMs are not
necessarily shielded. However, since this scenario still involves
nested virtualization, it falls into the same bucket from
prerequisites standpoint.
</p>
<p>
In either case, VSM of “Parent“ VM cannot benefit from
DMA protection. The reason is that Hyper-V does not provide a
virtual device with IOMMU functionality (an equivalent of
“Intel Virtualization Technology for Directed I/O” or
VT-d.)
</p>
<p>
So, if you configure Virtual Secure Mode for such scenarios, you
should not set it to require DMA protection. In other words, the
value of “RequirePlatformSecurityFeatures” parameter
should be <b>1</b> instead of <b>3</b>.
</p>
<p>
If you are curious what are the meanings of different numerical
values of “RequirePlatformSecurityFeatures”, they
<i>seem</i> to match those of “<a href="https://docs.microsoft.com/en-us/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity#requiredsecurityproperties">RequiredSecurityProperties</a>”
property of “Win32_DeviceGuard” WMI class. However,
the only officially documented values are <b>1</b> and <b>3</b>.
</p>
<p>
Anyhow, unless you intend to run “child” virtual
machines (shielded or otherwise) inside your “parent”
virtual machine, you do not need the nested virtualization feature.
Consequently, the DMA Protection limitation does not apply to your
scenario. You can safely expect that DMA Protection is available,
and hence require it. That is, set
“RequirePlatformSecurityFeatures” to <b>3</b>.
</p>
<p>
However, if you indeed aim to use Nested Virtualization, and hence relax
the DMA Protection requirement, please be aware that you are trading off
a valuable security feature—so you have to understand your scenario
and implications well.
</p>
<h4>Consequences</h4>
<p>
Strictly speaking, DMA protection functionality (IOMMU) does not make
sense for a virtualized environment anyhow—because there's no
DMA hardware in a virtual machine. (Unless you specifically enable
<a href="https://techcommunity.microsoft.com/t5/Networking-Blog/The-Evolution-of-RDMA-in-Windows-now-extended-to-Hyper-V-Guests/ba-p/339699">
Guest
RDMA
</a>.) If the “parent” VM is
shielded (e.g. in a “Repair Garage” scenario), it provides
sufficient protection from the host-based attacks, even in the absence of
DMA protection in the guest.
</p>
<p>
(The physical machine of course still needs this important
functionality. Please see <a href="#2.8. Shielded">below</a> for
details on Shielded VMs threats and countermeasures.)
</p>
<p>
In a typical lab scenario, however, the “parent” virtual
machine is typically <i>not</i> shielded, while the
“child” VMs might be. (Because, if you already can
run a Shielded VM as your “Level 1” VM—that is,
under a hypervisor running on bare metal—you probably do not
need to do that <i>in a lab</i> anymore.) In this configuration, the
“child” VM's secrets are expected to be secured
by the VSM running in the host—which in our case is
“parent” VM. However, as the latter is not shielded,
these secrets are still vulnerable to host-based attacks. Hence,
this is a perfectly valid lab scenario,
but it does not provide any real protection. It cannot be used for
vulnerability assessment, penetration testing or actual production
deployment.
</p>
</blockquote>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.7. TPM">2.7. I need to enable virtual TPM</h3>
<p>
Well this assumption is not as false as previous ones. However, it is
still false. In fact,
<a href="https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/tpm-recommendations#tpm-and-windows-features">you do not need a TPM</a>
to run Credential Guard. This is true for both physical (bare metal) and
virtual machines. So, a TPM is not strictly a requirement.
</p>
<p>
However, TPM is highly recommended. As
<a href="https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-requirements#baseline-protections">documentation</a>
says, “A TPM provides protection for VBS encryption keys that are
stored in the firmware. This helps protect against attacks involving a
<i>physically present user</i> with BIOS access.”
</p>
<p>
Please note the emphasis I added to previous paragraph. This is
very important for the <a href="#2.8. Shielded">following</a>
discussion.
</p>
<blockquote style="background-color:lightgrey; padding:15px">
<h4>Virtual TPM and VM identity</h4>
<p>
Virtual TPM (vTPM) is somewhat an unusual virtual device. While most
of VM devices can be added or removed, a virtual TPM can only be
<i>enabled or disabled.</i> Similarly to a physical TPM, soldered
on the motherboard, you cannot truly remove it, or replace with
an instance of another device. Even if you disable vTPM, and then
enable it back, it's still the original instance of the device
with the previously existing contents. Normally it does not matter,
but please keep this in mind in case of any troubleshooting or
security compromise.
</p>
<p>
You can clear or re-initialize a virtual TPM
similarly to a physical TPM. However, if for some reason you need
to actually <i>replace</i> it, you will need to create another VM
configuration from scratch. That would affect other
identities of the VM. Some of them are more or less easy to
change (to mimic those of original VM)—for instance, SMBIOS
GUID, Serial Number or MAC addresses of the vmNICs. However, some
other identities are very hard (if ever possible) to
modify—such as PNP IDs of virtual devices.
</p>
</blockquote>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.8. Shielded">
2.8. I need Shielded Virtual Machine
</h3>
<p>
To put it simply, you don't. There are no technical requirement to
have any of Shielded VMs features if you want to run Credential Guard or
any other feature powered by Virtual Secure Mode (e.g. HVCI.)
</p>
<blockquote style="background-color:lightgrey; padding:15px">
<h4>Devil in details</h4>
<p>
However, let's talk about threat modeling a little. As
explained above, having a TPM is <i>strongly advised</i>. Without a
TPM, your machine (or anything protected by VSM inside a machine)
is vulnerable for attacks by anyone with physical access. For a
physical, bare-metal machine, that's anyone hanging out nearby your
computer. Plain and simple. But for a virtual machine, the list
goes on and on. Virtualization is a blessing for IT because it
provides unprecedented abstraction and flexibility. But the direct
consequence of this abstraction is the need to rethink the concept
of “physical access”.
</p>
<p>
At very least, that includes anyone hanging out nearby your
virtualization host. However, <i>an equivalent</i> of physical
access includes anyone (no matter how <i>remote</i> they are) with
administrative privileges on the
virtualization host (e.g. your virtualization administrator). But
protecting the host itself is not enough. Because the list also
includes anyone with access to virtual
machine <i>files</i> in one way or another. For some
environments that might include the storage (SAN) administrator,
backup operator, antivirus administrator, whoever manages the
patching infrastructure, network administrator,
datacenter technicians—or even the hardware vendor who is
authorized to come in and swap bad parts in servers.
</p>
<p>
(From the standpoint of a
Shielded VMs implementation we call all these parties collectively
<i>“Fabric Administrators”</i>—however, this
might be confusing, especially considering what a
“Fabric” means in other contexts. We intentionally
unify them under a generic term
because they are all equally untrusted from the perspective of a VM
owner—the party we call <i>“a Tenant”).</i>
</p>
<p>
What I'm trying to say here, the concept of “physical
access” is very different comparing with that with a physical
computer. For a virtual machine, “physical access”
is… well, virtual.
</p>
<h4>And so what?</h4>
<p>
So, looking at the <a href="#2.7. TPM">above recommendation</a>
again, we should add a TPM to
mitigate the <i>physical presence</i> attack vector. Is that it?
Well, yes, if we were talking
about a physical machine. But with a virtual machine, that list of people
who have an equivalent of “physical access” might be endless.
</p>
<p>
For this very reason, simply adding a virtual TPM does not add
<i>anything</i> to our threat model.
Now instead of protecting the VM disk files, we need to protect much
smaller resource or configuration files (where the contents of
virtual TPM
lives.) Even though virtual TPM contents is always encrypted at rest,
the
encryption key has to be stored somewhere. And by default there's nowhere
else to store it other than the host itself. Which means it is still
perfectly accessible to anyone with access to the host (online or
offline.)
</p>
<p>
Yes, the purpose of Credential Guard is to protect from attacks from
within the same operating system (e.g. malicious
processes—such as Mimikatz.) In some
context, we can also call them <i>“in-guest”</i> or
<i>“online”</i> attacks.
If your threat model only counts for these types of attacks, running
Credential Guard (even <i>without</i> a TPM) would
address that. But if you also consider attack
at the host level (e.g. malicious or careless administrator),
we're just getting started.
</p>
<h4>So, what about host-based attacks? You have a magical checkbox for it, too?</h4>
<p>
Now we're talking. Unofrtunately, addressing this specific attack
vector is not easy at all. Turns out, to
do that comprehensively, you need a whole bunch of new things.
</p>
<p>
If you never thought of some of these things before, don't
blame yourself. Virtualization technologies evolved heavily over
the last couple decades. However, until very recently, they were
not considered mature enough, performing enough, or valuable enough
to gain prime-time attention for production and serve
real security-sensitive workloads. Moreover, the threat landscape
also evolved rapidly, and it took quite some time for malicious
actors (or your friendly pentesters) to start paying attention to
compromising virtualized assets. Finally, that all caused a
paradigm shift in how we think about security and
protection—and nowadays, <i>“assume breach”</i>
and <i>“defense in depth”</i> are hot topics.
</p>
<p>
And only when it all happened, we as an
industry started thinking of what's needed to provide
<i>physical-level</i>
security (or better) for virtualized world.
</p>
<ul>
<li>
Decouple the storage of protected secret (vTPM contents) from
the encryption key protecting this secret.
</li>
<li>
Offload key protection to an external authority which is not
controlled or accessible by virtualization host (“Fabric”)
administrators.
</li>
<li>
A mechanism to ensure that keys can only be decrypted by predefined
list of known such authorities. (Using the concept of public and
private keys.)
</li>
<li>
Because hosts still need access to the key when turning on the VMs or
accepting incoming live migrations, implement a mechanism of
delivering said key to the host and storing it host's secure
area (which is also based on Virtual Secure
Mode—ironically, here one application of security
technology helps to secure a separate, logically independent
instance of the very same technology. That's the beauty
of pluggable “trustlet” model.)
</li>
<li>
A protocol to ensure the abovementioned transfer is done
securely and only to authorized hosts.
</li>
<li>
Set up a comprehensive set of technical protections that prevent
host (or “Fabric”) administrators from intercepting
the keys or decrypted secrets
while VMs are running. That includes regular features protecting VSM,
such as DMA protection, as well as additional safeguards—such
as preventing debuggers, memory dump encryption, application
whitelisting (Device Guard Code Integrity or Windows Defender
Application Control, WDAC), etc.
</li>
<li>
A way to define, in a structured way, a known good set
(baseline) of host configuration—including all of the
protections mentioned above, and their settings (e.g. exact
Code Integrity policy applied.)
</li>
<li>
A mechanism to check (attest) a given host against the defined
baseline.
</li>
<li>
A mechanism to ensure that key delivery only happens when a host
passes attestation.
</li>
<li>
Yet another mechanism to ensure the previously obtained key is
invalidated
automatically should the host suddenly deviate from the
baseline (e.g. Code Integrity policy was modified or lifted.)
</li>
<li>
A framework to enforce protections on VM level (policy), so that
security properties are embedded into VM configuration and cannot be
arbitrarily changed by whoever has access to the host-level
settings or storage.
</li>
<li>
A mechanism to ensure that policy applies automatically to all new VMs
created by (or on behalf of) specific owner.
</li>
<li>
A mechanism to ensure that only known good media (“Clean
Source”) is used to provision a virtual machine. (Otherwise
an administrator or malware running at Fabric level could poison a VM
before it's even created.)
</li>
<li>
A mechanism to deliver VM specialization data (e.g. domain join
credentials or certificates) during provisioning in a secure manner
so that the VM maintains its identity from
the “day zero”. Otherwise,
there's no way to ensure that VM popped on the network is the actual
VM you provisioned (e.g. prevent MitM attack.)
</li>
<li>
At the same time, ensure that host administrators cannot sniff
or tamper with the abovementioned VM credentials.
</li>
<li>
Probably other things which are less important or which I forgot of.
</li>
</ul>
<p>
Shielded VMs <i>solution</i> address precisely the concerns above, so that
you can be confident that your secrets—while protected by Credential
Guard in the Guest—are immune to “physical
presence”-equivalent attacks at the host.
</p>
<h4>
Wait, so you first said that I do not need Shielded VMs, but now
you say I do?
</h4>
<p>
Yes, this is a classic example of <i>
“yes but actually
no”
</i>
scenario. You do not technically need Shielded VMs to enable
Credential Guard. However, you might consider this a requirement if
you assess the security of end-to-end solution. Or you might very
well dismiss this requirement if you rule host-based attacks out of
the picture and decide that hosts are ultimately trustworthy
“as is” without the need of policy enforcement or
attestation. (E.g. if you're running at a cloud provider which
you fully trust.) But again, in this case, you don't even need
a TPM in your machines. It does not provide any additional security
benefit. (Note that it still does make sense to enable Credential
Guard in such machines in order to protect from in-guest attacks.)
</p>
<p>
This gray sidebar is intended to help you make an
educated decision, not to push you in one direction or another.
</p>
<p>
Finally, it's worth mentioning that “Shielded VMs” term
is a bit overloaded. Having a VM “Shielded” by ticking a
checkbox in Hyper-V management interface will not magically deliver on
the security promise explained above. From the list of features above it
should be obvious that they work closely together and depend on one
another. Having only some parts of the solution will not help you much,
if ever. So, if you are interested in this comprehensive set of
protections you need to implement the whole Shielded VMs <i>solution</i>,
or infrastructure. That might include both technical features (e.g. Host
Guardian Service or HGS) as well as organizational or process-level
changes. The cornerstone of the Shielded VMs solution is <i>
role
separation
</i>, and you cannot
technically enforce it if there are no separate roles in your processes.
</p>
<p>
However, believe it or not, but planning a Shielded VMs implementation is
not the topic of this document. As such, let's get back to answering
the original question.
</p>
<p>
No, you do not need Shielded VMs for running
Credential Guard in the VMs. However, if your threat model includes not
only in-guest, but also host-based attack vectors (which is an
equivalent of “physical access” for virtual machines) you
definitely should implement the <i>full</i> Shielded VMs solution.
No other technology available in market today can deliver this
comprehensive set of protections. Moreover, a <i>partial</i>
implementation would not provide end-to-end security, because all
of the components depend on one another, back to back.
</p>
</blockquote>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="2.9. Encryption">2.9. I need Encryption-supported virtual machine</h3>
<p>
Encryption-supported VMs is a subset of Shielded VMs functionality. Or,
put it slightly different, it's an alternative <i>security policy</i>
option for virtual machines, on par with Shielded. They provide the
same virtual TPM functionality and offloaded key protection.
</p>
<p>
As such, Encryption-supported VMs rely on all the same
infrastructure as <i>
full
Shielded VMs solution.
</i> Just as with Shielded VMs, you cannot
have Encryption-supported VMs without deploying the full solution.
Having Encryption-supported instead of Shielded does not lower
any of the infrastructure requirements or eliminate the need for
any upfront investments.
</p>
<p>
However, Encryption-supported VMs provide slightly more
convenience—both for virtual machine owner
(“Tenant”) and host
(“Fabric”) administrator. As such, it might be a viable
alternative to Shielded VMs in some scenarios where you can trade
off some secuirty.
</p>
<p>
To reiterate, if your end goal is to run Credential Guard, you do not need
Encryption Supported VMs—just as you don't need Shielded VMs
either.
</p>
<p>
However, if your threat model assumes host-based
attack vectors, and you are looking at Shielded VMs to address those,
you can consider Encryption-supported VMs. But you
will need to carefully assess different available policy options and
validate them against your threat model before
deciding between Shielded or Encryption-supported.
</p>
<p>
<a href="#top">back to top</a>
</p>
<hr />
<h2 id="3. Truth">
3. What you actually need
</h2>
<p>
As I said multiple times already, you don't need to do
<i>anything.</i> However, I knew you won't simply believe me,
so here are some details.
</p>
<h3 id="3.1. Secure">
3.1. UEFI Secure Boot
</h3>
<p>
This is one of key requirements of Virtual Secure Mode, and
hence Credential Guard. However, it's enabled by default for all
Generation 2 virtual machines.
</p>
<blockquote style="background-color:lightgrey; padding:15px">
<p>
Note that technically you can enable VSM even without Secure Boot
by setting “RequirePlatformSecurityFeatures” to
<b>0</b>. That would even allow you to run VSM in a Generation 1
VM. (However, in this case you would <i>actually</i> need to enable
nested virtualization as well.)
</p>
<p>
By the way, that's how Guarded Host is enabled for Shielded
VMs in scenario where none of the physical security features
(Secure Boot, TPM and/or IOMMU) are available. This is typical for
a rather niche interim use case where you need “encryption
for the sake of encryption” (read: for compliance.) For such
scenarios, Shielded VMs architecture provides couple of less-secure
modes—namely, AD-based attestation or Host Key attestation.
</p>
<p>
However, based on the above, it should be already obvious
that such configuration do not provide any reasonable level of
protection. Without a TPM, you're vulnerable to offline attacks
(either with physical presence, or host-based.) Without Secure
Boot, you can expect even less. For instance, a malicious process
running <i>in Guest</i> can also compromise VSM right away by
tampering with the boot loader. As such, while technically
possible, this configuration is not supported for Credential Guard
whatsoever.
</p>
</blockquote>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="3.2. Generation">
3.2. Generation 2 Virtual Machine
</h3>
<p>
Secure Boot is UEFI feature. As such, it is only available for
Generation 2 virtual machines. There's no way to
“emulate” Secure Boot functionality for a legacy
BIOS-based machine.
</p>
<p>
(Even though some other features may be
available for Generation 1 virtual machines—such as BitLocker
with offloaded key protection.
This won't address any of VSM or Credential Guard requirements. So,
this is irrelevant for the topic of this document.)
</p>
<blockquote style="background-color:lightgrey; padding:15px">
<p>
Please do not abbreviate “Generation 2” as
<i>“Gen2”</i>. This sounds wrong. I mean, it's a common
mantra nowadays that <i>Microsoft loves Linux.</i> But not up to
the point of making our features <i>sound</i> indistinguishable
from a name of
a popular Linux distribution. Unless you're sending a telegram
and hence have to pay by the letter, please use full name of the
feature: “Generation 2”. Show a little respect. Trust
me, it does not hurt to type a little more.
</p>
</blockquote>
<p>
<a href="#top">back to top</a>
</p>
<h3 id="3.3. Guest VSM">
3.3. Guest Virtual Secure Mode (Guest VSM)
</h3>
<p>
This is a feature that actually allows you to run Virtual Secure
Mode without having a hypervisor running inside virtual machine.
Instead, it provides the required isolation services from the host
(while not compromising security.)
</p>
<p>
Similarly to Secure Boot, this feature is enabled <i>by default</i>
for all Generation 2 virtual machines (starting with <a href="https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server#what-happens-if-i-dont-upgrade-the-virtual-machine-configuration-version">
configuration
version 8.0
</a>.) You do not have do anything about it. That's the
whole point of this document.
</p>
<p>
If you're running on-premises, <i>there's no need</i> to