מהו Credential Guard וכיצד לבדוק אם הוא מופעל

הגנה על אישורים במערכת ההפעלה Windows הפכה למשימה קריטית עבור כל חברה שמתייחסת ברצינות לאבטחת סייבר. בכל פעם שמשתמש מתחבר, נוצרים ומאוחסנים אישורים. סודות אימות יקרי ערך ביותר (גיבובים, כרטיסים, טוקנים וכו') אשר, אם הם נופלים לידי תוקף, מאפשרים להם לנוע ברשת כאילו היו משתמשים לגיטימיים. כאן בדיוק נכנס לתמונה Credential Guard.

Windows Defender Credential Guard הוא תכונת אבטחה הממנפת את אבטחה מבוססת וירטואליזציה (VBS) כדי לבודד את הסודות הללו ולמנוע ממערכת ההפעלה "הרגילה" או מתוכנות זדוניות עם הרשאות מוגברות גישה אליהם. למרות שזה לא פתרון קסם ואינו מכסה את כל סוגי האישורים או את כל וקטורי התקיפה, זה מפחית באופן דרסטי את האפקטיביות של טכניקות קלאסיות כמו העבר את ה-Hash והעברת הכרטיסכמו גם כלים כמו Mimikatz בתרחישים רבים.

מה בדיוק זה Windows Defender Credential Guard?

Credential Guard היא תכונה של Windows שנועדה הגנה על אישורי דומיין וסודות אימות אחרים טכנולוגיה זו מגנה מפני התקפות המנסות לקרוא אותן ישירות מזיכרון המערכת. היא הופיעה לראשונה ב-Windows 10 Enterprise וב-Windows Server 2016, ועדיין קיימת בגרסאות מאוחרות יותר של Windows 11 ו-Windows Server.

באופן כללי, Credential Guard מסתמך על VBS כדי לבצע חלק מתהליך האבטחה ב... סביבה מבודדת על ידי ההיפר-ויזור, נפרד ממערכת ההפעלה הראשית. במקום שהסודות שוכנים ישירות בזיכרון של תהליך רשות האבטחה המקומית (LSA) המסורתי (lsass.exe), מאוחסנים בתהליך מוגן ועצמאי, המנוהל בדרך כלל על ידי LsaIso.exe, אשר ניתן לגשת אליו רק באמצעות הקוד המיומן והפריבילגי ביותר.

הפרדה זו נועדה למנוע מתוכנות זדוניות שצברו הרשאות מנהל מערכת פשוט dump את זיכרון ה-LSASS כדי לחלץ קוד גיבוב של NTLM, כרטיסי Kerberos או אישורים המאוחסנים במנהל האישורים. הגישה אינה לשנות את פרוטוקולי האימות, אלא כדי לאבטח היכן וכיצד מאוחסנים אישורים בזיכרון.

סודות ושירותים המוגנים על ידי Credential Guard

התכונה מגנה על סוגים שונים של אישורים אשר באופן מסורתי היוו מטרה עיקרית לתוקפים. בין הסודות ש-Credential Guard שומר מוגן נמנים, בעיקר, אלו הקשורים ל:

• NTLMגיבובי סיסמאות NTLM המשמשים לאימות.
• קרברוסבאופן ספציפי, כרטיס מתן כרטיסים (TGT) המאפשר לך לבקש כרטיסי שירות אחרים.
• מנהל אישוריםאישורי דומיין המאוחסנים על ידי יישומים ושירותים.
• כניסות מקומיות ומרוחקות שתלויים בתעודות הדומיין.

בגרסאות קודמות של Windows, סודות אלה היו בזיכרון התהליך. LSASS בצורה נגישה עבור תוקף עם הרשאות מוגברות. כאשר Credential Guard מופעל, פועל תהליך LSA מבודד שאינו חושף ישירות את הסודות הללו לכלים המנסים לקרוא את הזיכרון של מערכת ההפעלה הסטנדרטית.

כיצד פועלים אבטחה מבוססת וירטואליזציה (VBS) ומצב מאובטח וירטואלי (VSM)

המפתח ל-Credential Guard הוא VBS, טכנולוגיה המשתמשת ב-hypervisor של Windows כדי ליצור סביבות ביצוע מבודדות בתוך אותה מכונה פיזית. בתוך סביבה זו, המכונה לעתים קרובות מצב מאובטח וירטואלי (VSM), פועלים שירותי אבטחה המנהלים סודות אימות.

כאשר Credential Guard פעיל, סודות מאוחסנים בזיכרון בתוך VSM ולא ב- שטח זיכרון רגיל של מערכת הפעלהההיפר-ויזור מבטיח שרק קוד בעל הרשאות גבוהות ומאומת יוכל לגשת אליהם. בדרך זו, גם אם תוקף יצליח לפרוץ את מערכת ההפעלה עם הרשאות מנהל, הסיכויים שלו לקרוא את הסודות הללו ישירות מצטמצמים מאוד.

בחומרה מודרנית הכוללת TPM 2.0 תואם, ניתן להצפין נתונים מתמידים של VSM באמצעות מפתח ראשי של VSMמפתח זה מאוחסן ומוגן על ידי ה-TPM ומנגנוני שורש האמון שלו ברמת הקושחה. כתוצאה מכך, גם אם מישהו ינסה להתערב בתהליך האתחול או לשכפל דיסק, לא תוכל לגשת לסודות מוגנים מחוץ לסביבה מאומתת..

חשוב גם לציין ש-Credential Guard בדרך כלל אינו מאחסן נתונים כגון הדברים הבאים בדיסק: גיבוב NTLM או TGTאלה נוצרים מחדש בכל כניסה ואובדים בין אתחול מחדש, כך שהם אינם תלויים ישירות במפתח הראשי של VSM או ב-TPM כדי להישאר מאובטחים לאחר כיבוי.

מגבלות ואישורים ש-Credential Guard אינו מגן עליהם

למרות יתרונותיו, ל-Credential Guard יש מגבלות ברורות שצריך להבין כדי להימנע מביטחון יתר. ישנם זרימות אישורים ואימות שאינם מתחום ההגנה שלו או שפשוט אינם פועלים באותו אופן כאשר התכונה פעילה.

מצד אחד, כאשר Credential Guard מופעל, פרוטוקולים מדור קודם מסוימים כגון NTLMv1, MS-CHAPv2, תקציר ו-CredSSP הם לא יכולים להשתמש באישורים מהפעלה שכבר מחוברת. משמעות הדבר היא שכניסה יחידה (SSO) עם פרוטוקולים אלה מפסיקה לפעול. יישומים התלויים בהם עשויים להידרש לבקש שוב שם משתמש וסיסמה או להשתמש באישורים המאוחסנים במאגר Windows. אשר במקרים אלה אינם מוגנים על ידי Credential Guard.

יתר על כן, ישנן שיטות לניהול אישורים שאינן נכללות לחלוטין במסגרת תפקיד זה, כגון:

• תוכנה של צד שלישי שמאחסן סיסמאות או טוקנים מחוץ לתשתית הסטנדרטית של Windows.
• חשבונות מקומיים וחשבונות מיקרוסופט, אשר אינם נהנים מאותו סוג של בידוד כמו אישורי דומיין.
• מסדי נתונים של Active Directory מתארח על בקרי תחום של Windows Server. Credential Guard אינו מגן ישירות על מסד הנתונים של Active Directory או על צינורות הכניסה של אישורים בשירותים כגון Remote Desktop Gateway.
• לוגרי מפתחות ומכשירים אחרים ללכידת קלט: אם התוקף מקליט הקשות מקלדת, הוא יכול לגנוב את הסיסמה עוד לפני שהיא מאוחסנת ב-LSASS או בארגז החול.
• התקפות פיזיות לציוד (לדוגמה, גישה לזיכרון חם או קריאת דיסק באמצעות טכניקות מתקדמות).

כמו כן יש לציין כי Credential Guard אינו מונע גישה מתוקף שכבר יש לו תוכנה זדונית על המכונה. השתמש בהרשאות של אישורים תקפים שהושגו בדרכים חלופיות. לדוגמה, אם מנהל מערכת מתחבר למחשב שכבר נפרץ, התוקף יכול לנצל את הסשן הפעיל שלו כדי לבצע פעולות עם ההרשאות שלו, גם אם הוא אינו מסוגל לחלץ את קוד ה-hash של NTLM מסביבת ארגז החול.

מצד שני, ה- פרטי כניסה שמורים במטמון כניסות ל-Windows (הנקראות לעתים קרובות "כניסות מאוחסנות במטמון") גם אינן נופלות לקטגוריה של אישורים לשימוש חוזר במחשבים אחרים. הן מאוחסנות ברישום המקומי ומשמשות רק לאימות כניסות כאשר הדומיין אינו זמין. אלה מנוהלים על ידי מדיניות האבטחה "כניסה אינטראקטיבית: מספר כניסות קודמות למטמון" ו- הם אינם מוגנים במיוחד על ידי Credential Guard.

לבסוף, ה- שוברי שירות של Kerberos הם אינם מוגנים על ידי Credential Guard, למרות ש-TGT כן. וכאשר Credential Guard פעיל, Kerberos לא יאפשר האצלה בלתי מוגבלת או הצפנת DES, לא עבור אישורים שהוזמנו ולא עבור אישורים המבוקשים או שנשמרו.

יתרונות כנגד התקפות גניבת אישורים

המטרה העיקרית של Credential Guard היא לעצור התקפות של "גניבת ושימוש חוזר" באישורים, ובפרט:

• העבר את ה-Hashשימוש חוזר בקודי גיבוב גנובים של NTLM לצורך אימות במערכות אחרות.
• העבר את הכרטיסשימוש לרעה בכרטיסי Kerberos (TGT או שירות) שהתקבלו ממכונה שנפגעה.

על ידי בידוד סודות ב-VSM והגבלת מי שיכול לגשת אליהם, רבות מהטכניקות הממנפות כלים כמו Mimikatz חסומות. dump את זיכרון ה-LSASSבסביבה ללא Credential Guard, Mimikatz יכול לחלץ קוד גיבוב של NTLM וכרטיסי Kerberos ללא קושי רב לאחר שלתוקף יש הרשאות מנהל. כאשר Credential Guard מופעל, תהליך ה-LSA המבודד מונע סודות אלה להיות זמינים בזיכרון הנגיש ממערכת ההפעלה הסטנדרטית.

למרות זאת, חשוב להבין ש-Credential Guard אינו חסין מפני פגיעות. Mimikatz וכלים דומים עדיין יכולים, למשל, ללכוד אישורים בזמן הזנתםאם המערכת כבר נפגעה והמשתמש הפריבילגי מתחבר לאחר מכן, מחבר המאמר של מימיקץ הזהיר שאם התוקף ישיג שליטה על נקודת הקצה לפני שהמנהל מזין את פרטי הגישה שלו, עדיין יש דרכים לגנוב אותם. יתר על כן, Credential Guard אינו מגן מפני שימוש זדוני בפרטיות על ידי... משתמשים פנימיים לגיטימייםאם למישהו יש גישה מורשית למשאב, טכנולוגיה זו לא תמנע ממנו להעתיק נתונים רגישים.

מופעל כברירת מחדל ב-Windows 11 וב-Windows Server

בגרסאות האחרונות של המערכת, מיקרוסופט הלכה צעד קדימה ואפשרה את השילוב של VBS ושומר אישורי במכשירים מסוימים. החל מ-Windows 11, גרסה 22H2, ו-Windows Server 2025, במחשבים העומדים בדרישות המינימליות תכונות אלו מופעלות באופן אוטומטי.

הגדרת היצרן מתבצעת בדרך כלל ללא נעילת UEFIמשמעות הדבר היא שמנהלי מערכת יכולים להשבית מרחוק את Credential Guard אם הם סבורים שזה חיוני, למשל, עקב אי תאימות קריטית עם יישום מדור קודם. כאשר Credential Guard מופעל, גם VBS מופעל אוטומטית.

חשוב לדעת שאם לצוות כבר היה Credential Guard מושבת במפורש לפני שדרוג לגירסת Windows שבה התכונה מופעלת כברירת מחדל, המצב "מושבת" נשמר לאחר השדרוג. המדיניות המפורשת תמיד מקבלת עדיפות על פני אופן הפעולה המוגדר כברירת מחדל לאחר הפעלה מחדש.

דרישות חומרה, קושחה ותוכנה

כדי ש-Credential Guard יציע הגנה יעילה, המכשיר חייב לעמוד בדרישות דרישות מינימום לחומרה, קושחה ומערכת הפעלהככל שהחומרה מודרנית ושלמה יותר, כך רמת ההגנה הניתנת להשגה גבוהה יותר.

הדרישות המרכזיות כוללות:

• מעבד 64 סיביות, עם תמיכה בווירטואליזציה של חומרה.
• אבטחה מבוססת וירטואליזציה מופעל (VBS).
• הפעלה בטוחה מופעל ותצורתו מוגדרת.

בנוסף, למרות שלא תמיד חובה, מומלץ מאוד להצטייד ב:

• TPM (מודול פלטפורמה מהימנה) גרסה 1.2 או 2.0, נפרדת או קושחה, לקישור הגנה לחומרה ואחסון מאובטח של מפתחות ראשיים.
• נעילת UEFIאשר מונע מתוקף להשבית את Credential Guard פשוט על ידי שינוי ערכי רישום או שינויי תצורה ברמה נמוכה.

קבוצות העומדות בדרישות הבסיסיות הללו עשויות להיות זכאיות ל... דירוגי אבטחה נוספים ורמות הגנה גבוהות יותר מפני איומים המנסים לנצל את שרשרת האתחול או גישה ישירה לזיכרון.

שימוש ב-Credential Guard במכונות וירטואליות Hyper-V

Credential Guard יכול גם להגן על סודות בתוך מכונות וירטואליות הפועלות על Hyper-V, בדומה למצב שהוא עושה בחומרה פיזית. כאשר הוא מופעל במכונה וירטואלית, סודות מבודדים מהתקפות שמקורן ב... בתוך אותה מכונה וירטואלית.

עם זאת, ישנם ניואנסים חשובים: Credential Guard אינו מספק הגנה מפני התקפות של הרשאות מוגברות המופעלות מה- מְאָרֵחַ שהמכונה הווירטואלית מפעילה. כלומר, למנהל המערכת או לתוקף ששולט במערכת הפיזית הבסיסית עדיין עשויות להיות אפשרויות מניפולציה.

כדי ש-Credential Guard יפעל על מכונה וירטואלית Hyper-V, נדרשים לפחות הדברים הבאים:

• מארח Hyper-V עם איומו (יחידת ניהול זיכרון קלט/פלט) תואמת.
• מכונה וירטואלית של דור 2, התומך באתחול מאובטח של UEFI ובהרחבות הנדרשות.

מהמארח, ניתן אפילו להשבית את Credential Guard עבור מכונה וירטואלית ספציפית באמצעות PowerShell, עם פקודה דומה ל- Set-VMSecurity-VirtualizationBasedSecurityOptOut $true, מצביע על שם המכונה הווירטואלית.

רישיונות ומהדורות תואמים של Windows

Credential Guard אינו זמין בכל הגרסאות של Windows. מיקרוסופט שמרה אותו לגרסאות העסקיות והחינוכיות יותר, תוך השמטת מהדורות מקצועיות סטנדרטיות מסוימות.

לגבי תאימות לפי מהדורת Windows, באופן כללי, הדברים הבאים חלים:

• חלונות ארגוניים- תומך ב-Credential Guard.
• חלונות חינוך: תואם.
• Windows Pro ו-Windows Pro Education/SE: לא כוללים תמיכה ישירה עבור Credential Guard.

בנוגע לזכויות רישוי, הפונקציונליות קשורה למנויים ברמת ארגונים וברמת חינוך. בין הרישיונות ש... כן, הם מעניקים זכויות שימוש משמר האישורים כולל:

• חלונות ארגוניים E3
• חלונות ארגוניים E5
• חלונות חינוך A3
• חלונות חינוך A5

רישיונות אחרים, כגון Windows Pro או Pro Education Standard, אינם כוללים זכויות אלו כברירת מחדל. למידע מפורט יותר על מה כל רישיון כולל ואילו תרחישים הוא מכסה, מומלץ לעיין בתיעוד הרשמי. רישוי Windows.

השפעה על יישומי ופרוטוקולים של אימות

להפעלת Credential Guard יש השלכות ישירות בחלק מהמקרים פרוטוקולי אימות מדור קודם ופונקציונליות מסוימת של Kerberos ו-NTLM, שבהם יישומים מדור קודם רבים עדיין משתמשים. לפני פריסה המונית, חיוני לזהות דרישות ולבדוק תאימות.

היישומים יפסיקו לפעול כראוי אם הם דורשים אחת מהיכולות הבאות:

• תמיכה עבור הצפנת DES ב-Kerberos.
• האצלת Kerberos ללא הגבלות.
• הפקת קרברוס TGT מהמערכת.
• שימוש ב NTLMv1 כפרוטוקול אימות.

תרחישים אחרים לא בהכרח גורמים לתקלות באפליקציה, אבל הם כן להגביר את הסיכון לחשיפה של אישורים אם הם עדיין בשימוש:

• אימות מרומז שלוכד או משתמש מחדש באישורי טקסט רגיל.
• האצלת אישורים ללא אמצעי הגנה נאותים.
• פרוטוקולים כגון MS-CHAPv2 y קרדיטSSPמה שיכול לאלץ את המשתמש להזין אישורים אשר לאחר מכן מאוחסנים בצורה פחות מאובטחת.

שירותים או יישומים מסוימים שמנסים לקשר ישירות את התהליך המבודד LSAIso.exe הם עלולים לגרום לבעיות ביצועים או לתקלות אם הם לא מתוכננים לעבוד עם מודל חדש זה. לעומת זאת, שירותים המסתמכים על Kerberos כברירת מחדל, כגון שיתופי SMB או חיבורי שולחן עבודה מרוחק שתצורתם נכונה, הם אמורים להמשיך לתפקד כרגיל כאשר Credential Guard מופעל.

כיצד להפעיל את Credential Guard בסביבות ארגוניות

המלצת האבטחה היא להפעיל את Credential Guard. לפני צירוף מכשיר לדומיין או לפני שמשתמש תחום מתחבר בפעם הראשונה, כך שסודות לעולם לא יאוחסנו ללא הגנה משופרת. אם מופעל לאחר שהמכונה הייתה בשימוש במשך זמן מה, ייתכן שחלק מהאישורים כבר נפגעו.

ישנן מספר שיטות עיקריות להפעלת Credential Guard בצי של מכשירי Windows:

• מיקרוסופט אינטון / MDM.
• צו מדיניות קבוצתית (GPO).
• הגדרת רישום ישיר.

תצורה באמצעות Microsoft Intune ומדיניות MDM

בסביבה המנוהלת על ידי Intune, ניתן לפרוס תצורות באמצעות פרופילי אבטחה או מדיניות מותאמת אישית. תהליך העבודה האופייני כולל יצירת מדיניות הגנה על חשבון או מקבילה וקביעת הפרמטרים עבור הפעל את VBS וקבע את תצורת Credential Guard.

בעת שימוש ב-CSP (ספק שירותי תצורה) כגון DeviceGuard, המפתחות הרלוונטיים כוללים:

• שם תצורה: "הפעל אבטחה מבוססת וירטואליזציה". OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurityסוג נתונים: ערך שלם. 1 כדי לאפשר.
• שם תצורה: "תצורת Credential Guard". OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlagsסוג נתונים: שלם. ערכים אופייניים:
  • 1: מופעל עם נעילת UEFI.
  • 2: מופעל ללא חסימה.

לאחר שהמדיניות הוחלה על קבוצת המכשירים או המשתמשים הרצויה, יש צורך הפעל מחדש את המחשב כך שההיפר-ויזור וסביבת ה-VSM יאותחלו כראוי ושומר האישורים יהפוך לפעיל.

הפעלה באמצעות מדיניות קבוצתית (GPO)

בדומיינים מבוססי Active Directory, הדרך הקלאסית להגדיר את Credential Guard היא באמצעות עורך מדיניות קבוצתיתניתן להגדיר זאת הן בעורך המדיניות המקומית של כל מחשב והן ב-GPO המקושרים ל-OUs או לדומיין כולו.

נתיב התצורה הסטנדרטי הוא:

תצורת התקן ← תבניות ניהול ← מערכת ← Device Guard

בתוך נתיב זה, עליך לערוך את המדיניות "הפעל אבטחה מבוססת וירטואליזציה" ולהגדיר את הסטטוס שלה ל- מופעלבתפריט הנפתח "הגדרות של Credential Guard", ניתן לבחור בין "מופעל עם נעילת UEFI" או "מופעל ללא נעילה", בהתאם לרמת ההגבלה הרצויה. לאחר עדכון המדיניות והפעלה מחדש, ההגנה תהיה פעילה.

תצורה מתקדמת דרך הרישום

עבור תרחישים או אוטומציות ספציפיות, ניתן גם להגדיר את Credential Guard על ידי מניפולציה ישירה של רישום חלונותהמפתחות הרלוונטיים ביותר הם:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  מפתח: EnableVirtualizationBasedSecurity ערך (REG_DWORD): 1 כדי להפעיל את VBS.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  מפתח: RequirePlatformSecurityFeatures (REG_DWORD). ערכים אופייניים:
  • 1 לשימוש רק באתחול מאובטח.
  • 3 להשתמש באתחול מאובטח ובהגנה על DMA.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  מפתח: LsaCfgFlags ערכים: (REG_DWORD)
  • 1הפעל את Credential Guard עם נעילת UEFI.
  • 2הפעל את Credential Guard ללא נעילה.

לאחר יישום השינויים הללו, עליך הפעל מחדש את המכונה כדי שהתצורה החדשה תיכנס לתוקף והסביבה המוגנת תתחיל לפעול.

כיצד לבדוק אם Credential Guard באמת פועל

טעות נפוצה היא להתמקד אך ורק בשאלה האם התהליך LsaIso.exe זה מופיע במנהל המשימות, מה שמרמז ש-Credential Guard פעיל. מיקרוסופט אינה ממליצה על שיטה זו כבדיקה סופית, מכיוון שהיא עלולה... לא משקף במדויק את מצב ההגנה בפועל.

במקום זאת, ישנן שלוש שיטות אמינות יותר לבדוק את הסטטוס של Credential Guard:

• כְּלִי מידע מערכת (msinfo32.exe).
• קומנדו של פאוולסרל.
• סקירת אירועים ב- מציג אירועים.

עם מידע מערכת, פשוט הפעל msinfo32.exeבחר "סיכום מערכת" וסמן את השדה "הפעלת שירותי אבטחה מבוססי וירטואליזציה". אם "Credential Guard" מופיע בין השירותים הפעילים, פירוש הדבר ש הפונקציה אכן עובדת..

באמצעות PowerShell, ניתן להריץ את הפקודה:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

הערך המוחזר יציין את סטטוס הביצוע:

• 0: Credential Guard מושבת (לא פועל).
• 1Credential Guard מופעל ופעיל.

בנוסף, ניתן לסקור אירועים קשורים במציג האירועים, תוך סינון לפי Windows Logs\System עקב מקור האירועים WinInitניתוח תקופתי של אירועים אלה, בשילוב עם שאילתות WMI או ביקורות אבטחה, מסייע ב... לאשר את תקינות ומצב היישום על פני כל הצי.

אפשרויות להשבתת Credential Guard

למרות שזה לא אידיאלי מבחינה בטיחותית, לפעמים זה הכרחי בטל את משמר האישורים עקב בעיות תאימות עם יישומים קריטיים או פרוטוקולים מדור קודם שלא ניתן להחליף אותם בטווח הקצר.

ההליך להשבתת התכונה משתנה בהתאם לאופן שבו היא הופעלה בתחילה. באופן כללי, עליך:

• חזור על התצורה שהוחלת על ידי Intune, GPO או Registry, והחזר את ערכי VBS ו-LsaCfgFlags למצבם המושבת.
• הפעל מחדש את המכשיר כדי להפסיק את טעינת רכיבי אבטחה מבוססי וירטואליזציה.

אם Credential Guard הוגדר עם נעילת UEFIהדברים מסתבכים קצת יותר מכיוון שחלק מהמצב מאוחסן במשתני EFI בתוך הקושחה. במקרה זה, בנוסף לביטול התצורה ב-Windows, יש צורך להריץ סדרה של פקודות עם bcdedit משורת פקודה מוגבהת כדי לטעון כלי תצורה מיוחד (SecConfig.efi) במהלך ההפעלה.

הזרימה היא בדרך כלל משהו כזה:

• התקן מחיצת EFI זמנית באמצעות mountvol ולהעתיק את זה SecConfig.efi.
• צור ערך מטען מערכת עם bcdedit /createמצביע על SecConfig.efi.
• הגדר רצף אתחול זמני כדי לבצע ערך זה באתחול מחדש הבא ולהעביר לו את האפשרות השבתת LSA-ISO.
• הפעל מחדש את המכונה, וכאשר מופיעה הודעת טרום-אתחול, אשר את שינוי תצורת ה-UEFI כך שההשבתה תימשך.

ללא אישור זה, הקושחה לא תרשום את השינוי ו-Credential Guard יישאר נעול ברמת UEFI, גם אם התצורה שונתה בתוך מערכת ההפעלה.

במכונות וירטואליות, מארח Hyper-V יכול להשבית את השימוש ב-VBS וב-Credential Guard עבור מכונה וירטואלית ספציפית באמצעות פקודת PowerShell. הגדר-VMSecurity עם אפשרות ההדרה המתאימה.

בסביבות מסוימות, נצפה כי לאחר עדכוני Windows מסוימים, מחשבים שהשתמשו באימות שולחן עבודה מרוחק עם SSO או שיטות מדור קודם מתחילים להציג הודעות ש... האישורים אינם תקפים עודבמקרים רבים, הפתרון הזמני שיושם היה השבתת Credential Guard ממדיניות הקבוצה המקומית (GPEDIT.msc), ניווט אל תצורת מחשב ← תבניות מנהליות ← מערכת ← Device Guard ← "הפעל אבטחה מבוססת וירטואליזציה" וסימון אפשרות התצורה של Credential Guard כ"מושבת".

Credential Guard ביסס את עצמו כמרכיב מפתח באסטרטגיות הגנה על זהויות ב-Windows, במיוחד בסביבות עם Active Directory נרחב וחשבונות פריבילגיים רגישים ביותר. בידוד VBS, TPM וזיכרוןטכנולוגיה זו מקשה הרבה יותר על תוקפים המנסים לנוע לרוחב על ידי גניבת אישורים מזיכרון של נקודות קצה ושרתים, בתנאי שהיא משלימה על ידי שיטות עבודה מומלצות, כלי ניטור וניהול סביר של יישומים ופרוטוקולים מדור קודם.