Patch Critical Windows Vulnerabilities for 2024

As 2024 comes to a close, it’s es­sen­tial to re­flect on the im­por­tance of se­cur­ing our dig­i­tal in­fra­struc­ture. Through­out this year, crit­i­cal vul­ner­a­bil­i­ties have been dis­cov­ered in Win­dows sys­tems that could put or­ga­ni­za­tions and in­di­vid­u­als at risk. These vul­ner­a­bil­i­ties, if left un­ad­dressed, can lead to re­mote code ex­e­cu­tion, priv­i­lege es­ca­la­tion, and spoof­ing at­tacks.

 In this blog post, we will cov­er ac­tion­able steps to mit­i­gate sev­er­al of the most crit­i­cal vul­ner­a­bil­i­ties iden­ti­fied in Win­dows sys­tems this year, in­clud­ing CVE-2024-49112, CVE-2024-38200, CVE-2024-43533, and more. These steps will help en­sure that your sys­tems are se­cure as we head into the new year.

CVE-2024-49112: Win­dows Light­weight Di­rec­to­ry Ac­cess Pro­to­col (LDAP) Re­mote Code Ex­e­cu­tion Vul­ner­a­bil­i­ty

Step 1: Check Do­main Con­troller’s In­ter­net Ac­cess

1. Test if the do­main con­troller can ac­cess the in­ter­net:
   • The first step is to ver­i­fy if your do­main con­troller has di­rect in­ter­net ac­cess. This is im­por­tant be­cause at­tack­ers can ex­ploit do­main con­trollers via ex­ter­nal net­works if they are con­nect­ed to the in­ter­net.
     • Run the fol­low­ing Pow­er­Shell com­mand to test if the do­main con­troller can reach an ex­ter­nal serv­er (e.g., www.google.com).
2. InternetStatus = Test-NetConnection -ComputerName “www.google.com”
   • If the out­put shows that the do­main con­troller has in­ter­net ac­cess (PingSucceeded = True), pro­ceed to the next step to block this ac­cess.
   • If there is no in­ter­net ac­cess, your do­main con­troller is al­ready se­cure from this par­tic­u­lar vec­tor.
3. Block out­bound in­ter­net ac­cess (if in­ter­net ac­cess is de­tect­ed):
   • If the do­main con­troller has in­ter­net ac­cess, block all out­bound in­ter­net traf­fic by run­ning the fol­low­ing Pow­er­Shell com­mand:
   • New-NetFirewallRule -DisplayName “Block Outbound Internet Access” -Direction Outbound -Action Block -RemoteAddress “0.0.0.0/0”
   • This com­mand will block all out­bound traf­fic to ex­ter­nal des­ti­na­tions, ef­fec­tive­ly pre­vent­ing the do­main con­troller from reach­ing the in­ter­net and re­duc­ing ex­po­sure to ex­ter­nal threats.

Step 2: Block In­bound RPC Con­nec­tions from Un­trust­ed Net­works

1. Iden­ti­fy un­trust­ed net­work ranges:
   • To block ma­li­cious in­bound RPC con­nec­tions, iden­ti­fy un­trust­ed net­work ranges or ex­ter­nal IPs that should not be al­lowed to com­mu­ni­cate with your do­main con­troller.
   • Re­place the vari­able $untrustedNetworkRange with your ac­tu­al un­trust­ed IP range or sub­net (e.g., “10.0.0.0/8”).
2. Cre­ate a fire­wall rule to block in­bound RPC con­nec­tions:
   • Run the fol­low­ing Pow­er­Shell com­mand to block in­bound RPC con­nec­tions from un­trust­ed net­works. This rule ap­plies to the com­mon­ly used RPC ports 135, 139, and 445:
   • New-NetFirewallRule -DisplayName “Block Inbound RPC from Untrusted Networks” -Direction Inbound -Protocol TCP -LocalPort 135,139,445 -RemoteAddress $untrustedNetworkRange -Action Block
   • This ac­tion pre­vents at­tack­ers from ex­ploit­ing vul­ner­a­bil­i­ties in the RPC ser­vices via un­trust­ed net­works, adding an­oth­er lay­er of pro­tec­tion for your do­main con­troller.

Step 3: Ver­i­fy Mit­i­ga­tion Suc­cess

1. Con­firm in­ter­net ac­cess is blocked:
   • Run the fol­low­ing Pow­er­Shell com­mand to ver­i­fy that out­bound in­ter­net ac­cess has been suc­cess­ful­ly blocked:
   • Get-NetFirewallRule -DisplayName “Block Outbound Internet Access”
   • This will show if the fire­wall rule is ac­tive and cor­rect­ly block­ing all out­bound traf­fic.
2. Check in­bound RPC block:
   • Sim­i­lar­ly, con­firm that the in­bound RPC rule is in place by run­ning:
   • Get-NetFirewallRule -DisplayName “Block Inbound RPC from Untrusted Networks”
   • This en­sures that RPC con­nec­tions from un­trust­ed net­works are be­ing prop­er­ly blocked.

CVE-2024-38200 & CVE-2024-43609: Mi­crosoft Of­fice Spoof­ing Vul­ner­a­bil­i­ty

Step 1: Re­strict NTLM Out­go­ing Traf­fic Through Net­work Se­cu­ri­ty Poli­cies

1. Open Group Pol­i­cy Man­age­ment:
   • On your do­main con­troller, open the Group Pol­i­cy Man­age­ment Con­sole (GPMC). You can do this by run­ning gpmc.msc from the Run di­a­log or Pow­er­Shell.
2. Cre­ate a New Group Pol­i­cy Ob­ject (GPO):
   • In the GPMC, right-click your do­main and se­lect Cre­ate a GPO in this do­main, and Link it here. Name it some­thing like “Re­strict NTLM Out­go­ing Traf­fic.”
3. Edit the GPO:
   • Right-click the new GPO and se­lect Edit.
   • Nav­i­gate to Com­put­er Con­fig­u­ra­tion > Poli­cies > Ad­min­is­tra­tive Tem­plates > Sys­tem > Net­l­o­gon.
   • Lo­cate and en­able the pol­i­cy Re­strict NTLM: Out­go­ing NTLM traf­fic to re­mote servers. Set it to Block or Au­dit to re­strict NTLM traf­fic.
4. Ap­ply the GPO:
   • Af­ter con­fig­ur­ing the pol­i­cy, link it to the ap­pro­pri­ate Or­ga­ni­za­tion­al Units (OUs) in your do­main, en­sur­ing that it ap­plies to all do­main con­trollers and sys­tems re­quir­ing NTLM traf­fic re­stric­tions.
5. Ver­i­fy the Pol­i­cy:
   • Run the fol­low­ing com­mand to ver­i­fy that the GPO has been ap­plied:

                       gpresult /r

• En­sure that the NTLM re­stric­tion pol­i­cy is cor­rect­ly list­ed.

Step 2: Use the Pro­tect­ed Users Se­cu­ri­ty Group to Pre­vent NTLM Au­then­ti­ca­tion for Sen­si­tive Ac­counts

1. Add Sen­si­tive Ac­counts to the Pro­tect­ed Users Se­cu­ri­ty Group:
   • The Pro­tect­ed Users se­cu­ri­ty group helps mit­i­gate NTLM au­then­ti­ca­tion for sen­si­tive ac­counts, such as Do­main Ad­mins and En­ter­prise Ad­mins, by en­forc­ing mod­ern au­then­ti­ca­tion pro­to­cols like Ker­beros.
   • To add a user to the Pro­tect­ed Users group, run the fol­low­ing Pow­er­Shell com­mand:
   • Add-ADGroupMember -Identity “Protected Users” -Members “Domain Admins”
2. Re­place “Domain Admins” with any oth­er sen­si­tive ac­counts or groups you want to pro­tect.
3. Ver­i­fy Group Mem­ber­ship:
   • To ver­i­fy that the ac­counts have been added to the Pro­tect­ed Users group, run the fol­low­ing com­mand:
   • Get-ADGroupMember -Identity “Protected Users”
4. Mon­i­tor Po­ten­tial Im­pacts:
5. Note that some ap­pli­ca­tions may de­pend on NTLM for au­then­ti­ca­tion. Mon­i­tor the be­hav­ior of ap­pli­ca­tions that rely on NTLM and as­sess whether they are func­tion­ing cor­rect­ly af­ter en­forc­ing the Pro­tect­ed Users group.

Step 3: Block SMB Out­bound Traf­fic Us­ing Fire­walls and VPN Set­tings

1. Block SMB Traf­fic with a Fire­wall Rule:
   • Open Pow­er­Shell with ad­min­is­tra­tive priv­i­leges.
   • Run the fol­low­ing com­mand to block out­bound SMB traf­fic on ports 445 (used by SMB) and 139 (used for lega­cy SMB traf­fic):
   • New-NetFirewallRule -DisplayName “Block Outbound SMB Traffic” -Direction Outbound -Protocol TCP -LocalPort 445,139 -Action Block
2. Ap­ply the Rule to Your VPN Set­tings:
   • If you have a VPN that al­lows SMB traf­fic to pass through, con­fig­ure the VPN fire­wall set­tings to block out­bound SMB traf­fic (ports 445 and 139). Check your VPN provider’s doc­u­men­ta­tion for spe­cif­ic in­struc­tions on ap­ply­ing fire­wall rules.
3. Ver­i­fy the Fire­wall Rule:
   • To en­sure the SMB rule is ac­tive, run the fol­low­ing com­mand:
   • Get-NetFirewallRule -DisplayName “Block Outbound SMB Traffic”
4. En­sure that the rule is list­ed and set to Block.

Step 4: Mon­i­tor and Ver­i­fy Mit­i­ga­tion Suc­cess

1. Mon­i­tor NTLM Traf­fic:
   • Af­ter ap­ply­ing the NTLM traf­fic re­stric­tions, mon­i­tor your net­work for any un­ex­pect­ed au­then­ti­ca­tion fail­ures or is­sues with lega­cy ap­pli­ca­tions that re­quire NTLM. Use net­work mon­i­tor­ing tools like Wire­shark or Net­work Mon­i­tor to check for NTLM traf­fic.
2. Au­dit SMB Traf­fic:
   • Use au­dit­ing tools to mon­i­tor if any SMB traf­fic is still flow­ing through your net­work. This can be done us­ing Win­dows Event Logs or net­work se­cu­ri­ty ap­pli­ances that log and re­port out­bound traf­fic.
3. Check Ap­pli­ca­tion Com­pat­i­bil­i­ty:
   • Mon­i­tor the be­hav­ior of NTLM-de­pen­dent ap­pli­ca­tions to en­sure they are still func­tion­ing prop­er­ly. If any ap­pli­ca­tions fail, con­sid­er tran­si­tion­ing them to mod­ern au­then­ti­ca­tion meth­ods like Ker­beros or re­view­ing their com­pat­i­bil­i­ty with the changes.

CVE-2024-43571: Sudo for Win­dows Spoof­ing Vul­ner­a­bil­i­ty

Step 1: Dis­able Sudo Func­tion­al­i­ty via Sudo Pol­i­cy CSP

1. Open the Group Pol­i­cy Ed­i­tor:
   • Press Windows + R to open the Run di­a­log.
   • Type gpedit.msc and press En­ter to open the Group Pol­i­cy Ed­i­tor.
2. Nav­i­gate to the Sudo Pol­i­cy:
   • In the Group Pol­i­cy Ed­i­tor, go to:
     Computer Configuration > Administrative Templates > Windows Components > Device Guard
   • Un­der De­vice Guard, find the Sudo Pol­i­cy CSP.
3. Set the Mode to Dis­abled:
   • In the Sudo Pol­i­cy CSP sec­tion, se­lect EnableSudo.
   • Set the pol­i­cy to Dis­abled. This will dis­able all Sudo func­tion­al­i­ty in Win­dows.
4. Ap­ply the Pol­i­cy:
   • Af­ter set­ting the mode to Dis­abled, click OK to ap­ply the changes.
5. Test the Con­fig­u­ra­tion:
   • To ver­i­fy that the con­fig­u­ra­tion is work­ing, open a com­mand prompt and try run­ning a com­mand with sudo (e.g., sudo netstat -ab). It should print an er­ror mes­sage and exit, con­firm­ing that Sudo has been dis­abled.

Step 2: Dis­able Sudo via the Win­dows Set­tings Menu

1. Open the Set­tings Menu:
   • Press Windows + I to open Set­tings.
   • Nav­i­gate to Up­date & Se­cu­ri­ty > For De­vel­op­ers.
2. Choose a Con­fig­u­ra­tion Op­tion:
   • Un­der “For De­vel­op­ers”, you will see the con­fig­u­ra­tion op­tions for Sudo. You can choose the fol­low­ing:
     • Dis­abled: Com­plete­ly dis­ables Sudo func­tion­al­i­ty.
     • Force new win­dow: Launch­es the com­mand line ap­pli­ca­tion in a new con­sole win­dow when sudo is used.
     • Dis­able in­put: Launch­es the com­mand line ap­pli­ca­tion in the cur­rent con­sole win­dow but pre­vents the user from typ­ing any in­put.
     • Nor­mal: Al­lows the el­e­vat­ed process to re­ceive in­put from the cur­rent con­sole ses­sion (this is the de­fault be­hav­ior).
   • Set Sudo to Dis­abled:
     • Se­lect Dis­abled to dis­able Sudo en­tire­ly.
   • Ap­ply and Test the Set­tings:
     • Af­ter ap­ply­ing the changes, open a com­mand prompt and try run­ning a com­mand with sudo (e.g., sudo netstat -ab). The sys­tem should dis­play an er­ror mes­sage in­di­cat­ing that Sudo is not avail­able.

Step 3: Ver­i­fy and Mon­i­tor

1. Test Sudo Func­tion­al­i­ty:
   • Af­ter dis­abling Sudo, at­tempt to run a com­mand us­ing Sudo. If it has been prop­er­ly dis­abled, you should see an er­ror mes­sage and no com­mand will ex­e­cute with el­e­vat­ed priv­i­leges.
2. Mon­i­tor for Is­sues:
   • While dis­abling Sudo pre­vents ex­ploita­tion of the vul­ner­a­bil­i­ty, it might im­pact le­git­i­mate uses where Sudo is re­quired. Mon­i­tor for any is­sues with ad­min­is­tra­tive priv­i­leges and en­sure that ap­pli­ca­tions re­ly­ing on Sudo are ei­ther ad­just­ed or ap­pro­pri­ate­ly con­fig­ured.

CVE-2024-43533: Re­mote Desk­top Client Re­mote Code Ex­e­cu­tion Vul­ner­a­bil­i­ty

Step 1: Check if Re­mote Desk­top Ser­vices Are En­abled

• Step 1: Check if Re­mote Desk­top Ser­vices Are En­abled

1. Open the Sys­tem Prop­er­ties:
   • Press Windows + R to open the Run di­a­log.
   • Type sysdm.cpl and press En­ter to open Sys­tem Prop­er­ties.
2. Nav­i­gate to Re­mote Desk­top Set­tings:
   • In the Sys­tem Prop­er­ties win­dow, go to the Re­mote tab.
   • Un­der the Re­mote Desk­top sec­tion, check if Al­low re­mote con­nec­tions to this com­put­er is se­lect­ed. If it is, Re­mote Desk­top Ser­vices are en­abled on your sys­tem.

Step 2: Dis­able Re­mote Desk­top Ser­vices

Op­tion 1: Dis­able Re­mote Desk­top through Sys­tem Prop­er­ties

1. Open Sys­tem Prop­er­ties:
   • Fol­low the steps above to open Sys­tem Prop­er­ties.
2. Dis­able Re­mote Desk­top:
   • Un­der the Re­mote Desk­top sec­tion, se­lect “Don’t al­low re­mote con­nec­tions to this com­put­er.”
   • Click Ap­ply, then OK to save the changes.

Op­tion 2: Dis­able Re­mote Desk­top via Group Pol­i­cy (for Ad­min­is­tra­tors)

1. Open Group Pol­i­cy Ed­i­tor:
   • Press Windows + R, type gpedit.msc, and press En­ter to open the Lo­cal Group Pol­i­cy Ed­i­tor.
2. Nav­i­gate to Re­mote Desk­top Set­tings:
   • In the Lo­cal Group Pol­i­cy Ed­i­tor, go to:
     Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections
3. Dis­able Re­mote Desk­top Con­nec­tions:
   • Dou­ble-click the pol­i­cy named Al­low users to con­nect re­mote­ly by us­ing Re­mote Desk­top Ser­vices.
   • Set the pol­i­cy to Dis­abled
   • Click Ap­ply, then OK..

Op­tion 3: Dis­able Re­mote Desk­top via Win­dows Ser­vices

1. Open Ser­vices:
   • Press Windows + R, type services.msc, and press En­ter to open Ser­vices.
   • Stop and Dis­able the Re­mote Desk­top Ser­vices
     • Find Re­mote Desk­top Ser­vices in the list of ser­vices.
     • Right-click on Re­mote Desk­top Ser­vices, and se­lect Stop to stop the ser­vice.
     • To pre­vent the ser­vice from start­ing au­to­mat­i­cal­ly in the fu­ture, right-click on Re­mote Desk­top Ser­vices again, se­lect Prop­er­ties, and set the Start­up type to Dis­abled.
     • Click OK to ap­ply the changes.

Step 3: Ver­i­fy Re­mote Desk­top is Dis­abled

1. Check Sys­tem Prop­er­ties:
   • Go back to Sys­tem Prop­er­ties and ver­i­fy that Don’t al­low re­mote con­nec­tions to this com­put­er is se­lect­ed.
2. Ver­i­fy Ser­vice is Stopped:
   • Open Ser­vices and en­sure that Re­mote Desk­top Ser­vices is list­ed as Stopped and its Start­up type is set to Dis­abled.
3. Test Re­mote Desk­top:
   • Try con­nect­ing to your sys­tem via Re­mote Desk­top. If the ser­vice is prop­er­ly dis­abled, the con­nec­tion at­tempt should fail.

Step 4: Mon­i­tor and Re­view

1. Mon­i­tor for Changes:
   • Pe­ri­od­i­cal­ly check that Re­mote Desk­top re­mains dis­abled, es­pe­cial­ly af­ter sys­tem up­dates or changes.
2. Re­view Sys­tem Se­cu­ri­ty:
   • Make sure that any oth­er un­used or un­need­ed ser­vices are also dis­abled, as this will fur­ther re­duce the at­tack sur­face of your sys­tem.

CVE-2024-38189: Mi­crosoft Pro­ject Re­mote Code Ex­e­cu­tion Vul­ner­a­bil­i­ty

Step 1: Block Macros from Run­ning in Of­fice Files from the In­ter­net via Group Pol­i­cy

1. Open Group Pol­i­cy Man­age­ment:
   • On your do­main con­troller, open the Group Pol­i­cy Man­age­ment Con­sole (GPMC) by typ­ing gpmc.msc in the Run di­a­log.
2. Cre­ate a New Group Pol­i­cy Ob­ject (GPO):
   • Right-click your do­main in the Group Pol­i­cy Man­age­ment Con­sole and se­lect “Cre­ate a GPO” in this do­main, and Link it here.
   • Name the GPO some­thing like “Block Macros from In­ter­net Files.”
3. Edit the GPO:
   • Right-click the new­ly cre­at­ed GPO and se­lect Edit.
   • In the Group Pol­i­cy Man­age­ment Ed­i­tor, nav­i­gate to:
     User Configuration > Administrative Templates > Microsoft Office 2016 > Security Settings
   • Lo­cate the pol­i­cy named Block macros from run­ning in Of­fice files from the in­ter­net.
4. En­able the Pol­i­cy:
   • Dou­ble-click the pol­i­cy and se­lect En­abled.
   • When this pol­i­cy is en­abled, macros will be blocked even if the “En­able all macros” op­tion is se­lect­ed in the Trust Cen­ter. Users will see a no­ti­fi­ca­tion that macros are blocked.
5. Ex­cep­tions:
   • Macros will still be al­lowed if:
     • The Of­fice file is saved to a Trust­ed Lo­ca­tion.
       • The file was pre­vi­ous­ly trust­ed by the user.
       • Macros are dig­i­tal­ly signed, and the cor­re­spond­ing Trust­ed Pub­lish­er cer­tifi­cate is in­stalled.
     • Ap­ply the Pol­i­cy:
       • Af­ter en­abling the pol­i­cy, link it to the ap­pro­pri­ate Or­ga­ni­za­tion­al Units (OUs) con­tain­ing your tar­get users or com­put­ers.
     • Test the Pol­i­cy:
       • Af­ter ap­ply­ing the pol­i­cy, open an Of­fice file from the in­ter­net (e.g., an email at­tach­ment or a down­loaded file). The macro should be blocked, and you should see a no­ti­fi­ca­tion in­di­cat­ing that macros are blocked.

Step 2: En­able VBA Macro No­ti­fi­ca­tion Set­tings (Op­tion­al)

1. Open the Trust Cen­ter:
   • In any Of­fice ap­pli­ca­tion (e.g., Mi­crosoft Word or Ex­cel), go to File > Op­tions.
   • Se­lect Trust Cen­ter and then click Trust Cen­ter Set­tings.
2. Nav­i­gate to Macro Set­tings:
   • In the Trust Cen­ter, go to Macro Set­tings.
3. Con­fig­ure No­ti­fi­ca­tion Set­tings:
   • You can con­fig­ure Of­fice to dis­play no­ti­fi­ca­tions when macros are blocked, even if you don’t ex­plic­it­ly block macros from the in­ter­net.
   • Choose “Dis­able all macros with no­ti­fi­ca­tions”. This will no­ti­fy users when macros are blocked, and it will al­low them to en­able macros man­u­al­ly if need­ed.
4. Ap­ply the Set­tings:
   • Click OK to save the changes.

Step 3: Block Macros via the Reg­istry (Man­u­al Con­fig­u­ra­tion)

If you pre­fer to man­u­al­ly con­fig­ure the reg­istry in­stead of us­ing Group Pol­i­cy, you can block macros by mod­i­fy­ing the Win­dows Reg­istry.

1. Open the Reg­istry Ed­i­tor:
   • Press Windows + R, type regedit, and press En­ter to open the Reg­istry Ed­i­tor.
2. Nav­i­gate to the Mi­crosoft Of­fice Se­cu­ri­ty Reg­istry Path:
   • Go to the fol­low­ing reg­istry path:
     HKEY_CURRENT_USER\software\policies\microsoft\office\16.0\powerpoint\security
3. Cre­ate the Reg­istry Val­ue:
   • Right-click on the se­cu­ri­ty key and se­lect New > DWORD (32-bit) Val­ue.
   • Name the new val­ue “block­con­tentex­e­cu­tion­frominter­net.”
4. Set the Val­ue:
   • Dou­ble-click the new reg­istry en­try block­con­tentex­e­cu­tion­frominter­net and set the val­ue to 1 to en­able block­ing of macros from the in­ter­net.
   • Set the val­ue to 0 if you wish to dis­able the block (not rec­om­mend­ed for mit­i­ga­tion).
5. Exit Reg­istry Ed­i­tor:
   • Close the Reg­istry Ed­i­tor af­ter mak­ing the changes.
6. Ver­i­fy the Changes:
   • Open an Of­fice file from the in­ter­net and ver­i­fy that the macros are blocked. If they are, you will see a no­ti­fi­ca­tion in­form­ing the user of the block.

Step 4: Mon­i­tor and Re­view

1. Mon­i­tor for Any Is­sues:
   • Af­ter im­ple­ment­ing the changes, mon­i­tor your net­work for any is­sues re­lat­ed to le­git­i­mate files re­quir­ing macros. En­sure that the trust­ed lo­ca­tions and trust­ed pub­lish­er ex­cep­tions work cor­rect­ly.
2. Re­view Macro Set­tings:
   • Pe­ri­od­i­cal­ly re­view and test the macro set­tings to en­sure that any se­cu­ri­ty risks re­lat­ed to macros in Of­fice files are prop­er­ly mit­i­gat­ed.

CVE-2024-38159 & CVE-2024-38160: Win­dows Net­work Vir­tu­al­iza­tion Re­mote Code Ex­e­cu­tion Vul­ner­a­bil­i­ty

Step 1: Dis­able Hy­per-V and Re­lat­ed Fea­tures (VBS) on the Host

Op­tion 1: Dis­able Hy­per-V via Con­trol Pan­el

1. Open Con­trol Pan­el:
   • Press Windows + R to open the Run di­a­log, type control, and press En­ter to open the Con­trol Pan­el.
2. Go to Pro­grams and Fea­tures:
   • In the Con­trol Pan­el, se­lect Pro­grams and then click on Turn Win­dows fea­tures on or off.
3. Dis­able Hy­per-V Fea­tures:
   • Scroll down and find Hy­per-V and Hy­per-V Plat­form in the list of Win­dows fea­tures.
   • De­s­e­lect the fol­low­ing:
   • Hy­per-V Hy­per­vi­sor
   • Hy­per-V Man­age­ment Tools
   • Hy­per-V Plat­form
4. Click OK to ap­ply the changes.
5. Restart Your Com­put­er:
   • Restart your sys­tem to ap­ply the changes.
6. Check if Vir­tu­al­iza­tion-Based Se­cu­ri­ty is Dis­abled:
   • Af­ter restart­ing, press Windows + R, type msinfo32, and press En­ter to open Sys­tem In­for­ma­tion.
   • Check if Vir­tu­al­iza­tion-Based Se­cu­ri­ty is list­ed as “not en­abled.” If it is, Hy­per-V and re­lat­ed fea­tures are suc­cess­ful­ly dis­abled.

Op­tion 2: Dis­able VBS (Vir­tu­al­iza­tion-Based Se­cu­ri­ty) via Set­tings and Reg­istry

1. Dis­able Mem­o­ry In­tegri­ty via Win­dows Se­cu­ri­ty:
   • Open the Win­dows Se­cu­ri­ty app by search­ing for “Win­dows Se­cu­ri­ty” in the Start menu.
     • Go to De­vice Se­cu­ri­ty > Core Iso­la­tion.
       • Tog­gle Mem­o­ry In­tegri­ty to Off.
       • Restart your com­put­er.
     • Dis­able VBS via the Reg­istry:
       • Press Windows + R, type regedit, and press En­ter to open the Reg­istry Ed­i­tor
       • Nav­i­gate to the fol­low­ing reg­istry path:
         HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard
       • Find the En­able­Vir­tu­al­iza­tion­Based­Se­cu­ri­ty en­try and set its val­ue to 0 to dis­able Vir­tu­al­iza­tion-Based Se­cu­ri­ty.
       • Close Reged­it and re­boot your com­put­er to ap­ply the changes.

Step 2: En­able Nest­ed Vir­tu­al­iza­tion on VMware

1. En­sure VMware is In­stalled:
   • Make sure your VM is run­ning on VMware with nest­ed vir­tu­al­iza­tion en­abled. This will al­low you to run vir­tu­al­ized en­vi­ron­ments in­side your vir­tu­al ma­chine.
2. En­able Nest­ed Vir­tu­al­iza­tion in VMware:
   • Open VMware and se­lect the vir­tu­al ma­chine you want to con­fig­ure.
   • Right-click on the VM and se­lect Set­tings.
   • In the VM Op­tions tab, un­der CPU, en­able Vir­tu­al­ize In­tel VT-x/EPT or AMD-V/RVI. This op­tion en­ables nest­ed vir­tu­al­iza­tion with­in the VM.
3. Ver­i­fy Nest­ed Vir­tu­al­iza­tion:
   • En­sure the VM is run­ning prop­er­ly with nest­ed vir­tu­al­iza­tion en­abled by check­ing the VMware logs or run­ning a test that re­quires vir­tu­al­iza­tion with­in the VM.

Step 3: Ver­i­fy and Mon­i­tor the Con­fig­u­ra­tion

1. Check Hy­per-V Sta­tus:
   • Af­ter com­plet­ing the above steps, en­sure that Hy­per-V is ful­ly dis­abled and that VBS is not en­abled by fol­low­ing the ver­i­fi­ca­tion steps pro­vid­ed in Step 1.
   • Ver­i­fy that vir­tu­al­iza­tion is prop­er­ly dis­abled on the host ma­chine, and the VM is run­ning on VMware with nest­ed vir­tu­al­iza­tion en­abled.
2. Mon­i­tor Per­for­mance:
   • Mon­i­tor your sys­tem for any per­for­mance changes af­ter dis­abling VBS. Some users have re­port­ed a per­for­mance boost of up to 15% when VBS is dis­abled, but keep in mind that VBS of­fers ad­di­tion­al se­cu­ri­ty pro­tec­tion. You should only dis­able it if you’re cau­tious about se­cu­ri­ty risks, such as brows­ing the in­ter­net.
3. Test Vir­tu­al Ma­chine Func­tion­al­i­ty:
   • En­sure that the VM on VMware is func­tion­ing as ex­pect­ed with the nec­es­sary con­fig­u­ra­tions for nest­ed vir­tu­al­iza­tion.

CVE-2024-38074 & CVE-2024-38077: Win­dows Re­mote Desk­top Li­cens­ing Ser­vice Re­mote Code Ex­e­cu­tion Vul­ner­a­bil­i­ty

Step 1: De­ac­ti­vate the Re­mote Desk­top Li­cens­ing Ser­vice

1. Open Serv­er Man­ag­er:
   • On your Win­dows Serv­er, press Win­dows + R, type servermanager, and press En­ter to open Serv­er Man­ag­er.
2. Nav­i­gate to Re­mote Desk­top Li­cens­ing Man­ag­er:
   • In Serv­er Man­ag­er, click on Tools in the top-right cor­ner.
   • From the drop­down, se­lect Re­mote Desk­top Ser­vices, then Re­mote Desk­top Li­cens­ing Man­ag­er.
3. Right-click the Li­cense Serv­er:
   • In the Re­mote Desk­top Li­cens­ing Man­ag­er, right-click the li­cense serv­er you wish to de­ac­ti­vate.
   • From the con­text menu, se­lect Ad­vanced, then click De­ac­ti­vate Serv­er.
4. Fol­low the De­ac­ti­va­tion Wiz­ard:
   • The De­ac­ti­vate Serv­er Wiz­ard will ap­pear. Con­firm the in­for­ma­tion about the li­cense serv­er.
   • Click Next and then Fin­ish to de­ac­ti­vate the serv­er.
5. Ver­i­fy the De­ac­ti­va­tion:
   • To ver­i­fy that the de­ac­ti­va­tion was suc­cess­ful, use the RD Li­cens­ing Di­ag­nos­tic tool:
     • Go to Tools in Serv­er Man­ag­er, then se­lect RD Li­cens­ing Di­ag­nos­tic.
     • This will pro­vide you with the sta­tus of the Re­mote Desk­top Li­cens­ing Ser­vice and con­firm that it has been prop­er­ly de­ac­ti­vat­ed.

Step 2: Unin­stall Re­mote Desk­top Li­cens­ing Ser­vice (if not need­ed)

1. Open Apps and Fea­tures:
   • Press Win­dows + I to open Set­tings.
   • Nav­i­gate to Apps and then click on Apps & Fea­tures.
2. Find Re­mote Desk­top Ser­vices:
   • Scroll through the list of in­stalled ap­pli­ca­tions to find Re­mote Desk­top Ser­vices or Re­mote Desk­top Li­cens­ing.
3. Unin­stall the Ser­vice:
   • Click on Re­mote Desk­top Ser­vices or Re­mote Desk­top Li­cens­ing, then se­lect Unin­stall.
   • Fol­low the prompts to com­plete the unin­stal­la­tion process.

Step 3: Ver­i­fy the Re­mote Desk­top Li­cens­ing Ser­vice is Dis­abled

1. Check Sys­tem Ser­vices:
   • Press Win­dows + R, type services.msc, and press En­ter to open the Ser­vices win­dow.
   • Look for Re­mote Desk­top Li­cens­ing in the list of ser­vices.
     • En­sure that the ser­vice is ei­ther stopped or unin­stalled.
2. Test Re­mote Desk­top Func­tion­al­i­ty:
   • If you need Re­mote Desk­top for ad­min­is­tra­tive pur­pos­es, en­sure that oth­er RDS com­po­nents (such as Re­mote Desk­top Ses­sion Host) are still op­er­a­tional while the Li­cens­ing Ser­vice is dis­abled.
   • Con­firm that no Re­mote Desk­top li­cens­ing-re­lat­ed er­rors are oc­cur­ring when at­tempt­ing to use the RDS fea­tures.

Step 4: Con­sid­er Ad­di­tion­al Se­cu­ri­ty Mea­sures

1. Dis­able RDP Ac­cess if Not Need­ed:
   • If Re­mote Desk­top is not re­quired, dis­able RDP on the ma­chine to pre­vent re­mote ac­cess.
   • Go to Con­trol Pan­el > Sys­tem and Se­cu­ri­ty > Sys­tem > Re­mote set­tings.
   • Un­der Re­mote Desk­top, se­lect Don’t al­low re­mote con­nec­tions to this com­put­er.
2. Ap­ply Win­dows Up­dates:
   • En­sure your sys­tem is ful­ly patched with the lat­est Win­dows up­dates to mit­i­gate any known vul­ner­a­bil­i­ties in RDS or the Re­mote Desk­top Li­cens­ing Ser­vice.
   • Go to Set­tings > Up­date & Se­cu­ri­ty > Win­dows Up­date, and check for any avail­able up­dates.

Step 5: Mon­i­tor the Sys­tem for Un­want­ed Re­mote Ac­cess

1. Use Net­work Mon­i­tor­ing Tools:
   • Em­ploy net­work mon­i­tor­ing tools such as Wire­shark or Net­Flow to mon­i­tor any un­usu­al re­mote ac­cess traf­fic.
   • En­sure that no unau­tho­rized ac­cess is oc­cur­ring, even if Re­mote Desk­top has been dis­abled.
2. Run Mal­ware Scans:
   • Use trust­ed an­tivirus and anti-mal­ware soft­ware to scan for any po­ten­tial threats that might en­able re­mote ac­cess de­spite RDP be­ing dis­abled.
   • Ver­i­fy Fire­wall Set­tings
     • En­sure that the fire­wall is prop­er­ly con­fig­ured to block un­nec­es­sary ports. Par­tic­u­lar­ly, ver­i­fy that Port 3389 (used for RDP) is blocked if RDP is not in use.

CVE-2024-38061: DCOM Re­mote Cross-Ses­sion Ac­ti­va­tion El­e­va­tion of Priv­i­lege Vul­ner­a­bil­i­ty

Step 1: Mod­i­fy the Reg­istry to Set Lega­cyAu­then­ti­ca­tion­Lev­el

1. Open the Reg­istry Ed­i­tor:
   • Press Windows + R, type regedit, and press En­ter to open the Reg­istry Ed­i­tor.
2. Nav­i­gate to the Reg­istry Key:
   • In the Reg­istry Ed­i­tor, nav­i­gate to the fol­low­ing path:
     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
3. Cre­ate or Mod­i­fy the LegacyAuthenticationLevel En­try:
   • Right-click on the Ole fold­er in the left pane.
   • Se­lect New > DWORD (32-bit) Val­ue.
   • Name the new en­try Lega­cyAu­then­ti­ca­tion­Lev­el.
     • Dou­ble-click on the LegacyAuthenticationLevel en­try to mod­i­fy it.
     • Set the Val­ue data to 5 to set the au­then­ti­ca­tion lev­el to RPC_C_AU­THN_LEV­EL_PKT_IN­TEGRI­TY.
       • This set­ting en­sures pack­et in­tegri­ty is en­forced for DCOM com­mu­ni­ca­tions, adding an ex­tra lay­er of se­cu­ri­ty.
     • Click OK to save the changes.

Val­ue	Con­stant
1	RPC_C_AU­THN_LEV­EL_NONE
2	RPC_C_AU­THN_LEV­EL_CON­NECT
3	RPC_C_AU­THN_LEV­EL_CALL
4	RPC_C_AU­THN_LEV­EL_PKT
5	RPC_C_AU­THN_LEV­EL_PKT_IN­TEGRI­TY (Rec­om­mend­ed for mit­i­ga­tion)
6	RPC_C_AU­THN_LEV­EL_PKT_PRI­VA­CY

Step 2: Restart the Sys­tem

1. Af­ter mod­i­fy­ing the reg­istry, restart your sys­tem to en­sure that the new set­tings take ef­fect.

Step 3: Ver­i­fy the Change

1. Check the Reg­istry:
   • Re­open the Reg­istry Ed­i­tor and nav­i­gate to the same path (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole).
   • Ver­i­fy that the LegacyAuthenticationLevel val­ue is set to 5.
2. Check the DCOM Be­hav­ior:
   • Use di­ag­nos­tic tools or sim­ply mon­i­tor the sys­tem to en­sure that DCOM op­er­a­tions are not en­coun­ter­ing er­rors due to the stricter se­cu­ri­ty set­tings. The goal is to en­sure that RPC_C_AU­THN_LEV­EL_PKT_IN­TEGRI­TY is prop­er­ly ap­plied.

Step 4: Mon­i­tor the Sys­tem for Any Is­sues

1. Test DCOM func­tion­al­i­ty: Af­ter ap­ply­ing the reg­istry change, en­sure that your sys­tem’s DCOM func­tion­al­i­ty op­er­ates cor­rect­ly. Since this ad­just­ment mod­i­fies the de­fault au­then­ti­ca­tion lev­el for DCOM, there may be a po­ten­tial im­pact on back­ward com­pat­i­bil­i­ty for cer­tain ap­pli­ca­tions re­ly­ing on low­er lev­els of au­then­ti­ca­tion.
2. Mon­i­tor sys­tem logs: Keep an eye on the Event View­er and look for any warn­ings or er­rors re­lat­ed to DCOM or RPC com­mu­ni­ca­tions to en­sure that the change hasn’t caused any un­in­tend­ed is­sues.

CVE-2024-26232 & CVE-2024-30080: Mi­crosoft Mes­sage Queu­ing (MSMQ) Re­mote Code Ex­e­cu­tion Vul­ner­a­bil­i­ty

Step 1: Check if MSMQ HTTP-Sup­port is En­abled

1. Open Win­dows Fea­tures:
   • Press Win­dows + R, type optionalfeatures.exe, and press En­ter to open the Win­dows Fea­tures di­a­log.
2. Lo­cate MSMQ:
   • Scroll through the list and find Mi­crosoft Mes­sage Queu­ing (MSMQ).
3. Dis­able MSMQ HTTP-Sup­port:
   • If MSMQ HTTP Sup­port is checked, uncheck it to dis­able the fea­ture.
   • Click OK to ap­ply the changes.
   • Al­ter­na­tive­ly, you can also dis­able MSMQ HTTP-Sup­port via Pow­er­Shell:
     Disable-WindowsOptionalFeature -Online -FeatureName MSMQ-HTTP
4. Restart the Sys­tem:
   • Restart the sys­tem for the changes to take ef­fect.

Step 2: Check if MSMQ Ser­vice is Run­ning

1. Open Ser­vices:
   • Press Win­dows + R, type services.msc, and press En­ter to open the Ser­vices win­dow.
2. Check MSMQ Ser­vice:
   • Look for the Mes­sage Queu­ing (MSMQ) ser­vice in the list of ser­vices.
   • If the ser­vice is run­ning and you don’t re­quire MSMQ, right-click on it and se­lect Stop.
   • To dis­able the ser­vice from start­ing au­to­mat­i­cal­ly, right-click on the ser­vice, se­lect Prop­er­ties, and set the Start­up type to Dis­abled.
   • You can also dis­able the ser­vice via Pow­er­Shell:
     Set-Service -Name MSMQ -StartupType Disabled
3. Stop-Service -Name MSMQ

Step 3: Check if TCP Port 1801 is Open

1. Open Com­mand Prompt:
   • Press Win­dows + R, type cmd, and press En­ter to open the Com­mand Prompt.
2. Check if TCP Port 1801 is Lis­ten­ing:
   • Run the fol­low­ing com­mand to check if TCP port 1801 is open and if the MSMQ ser­vice is lis­ten­ing on that port: netstat -an | find “1801”
3. If port 1801 is open and you don’t re­quire MSMQ, you should block this port through the fire­wall.
4. Block Port 1801 Us­ing Win­dows Fire­wall:
   • To block TCP port 1801, open Win­dows De­fend­er Fire­wall by typ­ing firewall.cpl in the Run di­a­log.
   • In the left pan­el, click on Ad­vanced set­tings to open Win­dows Fire­wall with Ad­vanced Se­cu­ri­ty.
     • Click In­bound Rules > New Rule.
     • Se­lect Port, choose TCP, and en­ter 1801 as the port to block.
     • Choose Block the con­nec­tion and fol­low the prompts to com­plete the rule cre­ation.
   • Ver­i­fy Fire­wall Rule:
     • En­sure the fire­wall rule is ap­plied and that the port is now blocked. You can use netstat again to ver­i­fy that port 1801 is no longer open.

Step 4: Mon­i­tor and Test the Con­fig­u­ra­tion

1. Ver­i­fy MSMQ Con­fig­u­ra­tion:
   • Af­ter dis­abling MSMQ HTTP-Sup­port, stop­ping the MSMQ ser­vice, and block­ing port 1801, ver­i­fy the set­tings by at­tempt­ing to con­nect to the sys­tem via port 1801 and en­sur­ing that the con­nec­tion is blocked.
   • Use net­work scan­ning tools (like Nmap) to en­sure the port is closed and not ex­posed.
2. Test Ap­pli­ca­tion De­pen­den­cies:
   • If your en­vi­ron­ment re­lies on MSMQ for ap­pli­ca­tion com­mu­ni­ca­tion, test whether ap­pli­ca­tions are still func­tion­al af­ter dis­abling the ser­vice and block­ing the port. If MSMQ is nec­es­sary for cer­tain ap­pli­ca­tions, con­sid­er lim­it­ing ac­cess to trust­ed net­works and prop­er­ly se­cur­ing the ser­vice.

CVE-2021-43890 (Win­dows AppX In­staller Spoof­ing Vul­ner­a­bil­i­ty

Step 1: In­stall the Lat­est Ver­sion of App In­staller (1.21.3421.0 or Greater)

1. Check Your Cur­rent Ver­sion:
   • To check the cur­rent ver­sion of the App In­staller on your sys­tem, open Pow­er­Shell and run the fol­low­ing com­mand:
   • (Get-AppxPackage Microsoft.DesktopAppInstaller).Version
2. This will re­turn the cur­rent ver­sion of App In­staller in­stalled on your sys­tem.
3. Up­date App In­staller Us­ing the Mi­crosoft Store:
   • If the App In­staller is not up-to-date, open the Mi­crosoft Store app on your PC.
   • Search for App In­staller and check for avail­able up­dates.
   • If an up­date is avail­able, click Up­date to in­stall the lat­est ver­sion.
4. Up­date App In­staller Us­ing Winget (If Mi­crosoft Store is Un­avail­able):
   • If your PC doesn’t have ac­cess to the Mi­crosoft Store, you can up­date the App In­staller us­ing Winget.
   • Open Com­mand Prompt or Pow­er­Shell and run the fol­low­ing com­mand:
     • winget upgrade Microsoft.AppInstaller
   • This com­mand will up­date the App In­staller to the lat­est ver­sion.
5. Ver­i­fy the Up­date:
   • Af­ter up­dat­ing, re-run the Pow­er­Shell com­mand from Step 1 to ver­i­fy that the App In­staller ver­sion is now 1.21.3421.0 or greater.

Step 2: Mon­i­tor and Ver­i­fy the Mit­i­ga­tion

1. Ver­i­fy App In­staller Up­date:
   • Af­ter up­dat­ing to the lat­est ver­sion or dis­abling the pro­to­col, ver­i­fy that the ms-ap­pin­staller pro­to­col is no longer ex­posed (if you dis­abled it via Group Pol­i­cy) and that App In­staller is run­ning the lat­est ver­sion.
2. Test In­stal­la­tion of MSIX Files:
   • Test the in­stal­la­tion of MSIX or MSIXBun­dle files to en­sure that the App In­staller is func­tion­ing prop­er­ly with the new con­fig­u­ra­tion.
3. Check for Any Er­rors or Warn­ings:
   • Open Event View­er and mon­i­tor for any er­rors or warn­ings re­lat­ed to App In­staller or MSIX in­stal­la­tions to en­sure the changes have not im­pact­ed func­tion­al­i­ty.

Con­clu­sion

As 2024 comes to an end, ad­dress­ing these crit­i­cal Win­dows vul­ner­a­bil­i­ties is a pri­or­i­ty for IT pro­fes­sion­als and or­ga­ni­za­tions alike. Im­ple­ment­ing the rec­om­mend­ed mit­i­ga­tion strate­gies will sig­nif­i­cant­ly en­hance your se­cu­ri­ty pos­ture and re­duce the risk of ex­ploita­tion. Whether it’s through up­dat­ing vul­ner­a­ble soft­ware, dis­abling un­nec­es­sary ser­vices, or ap­ply­ing group pol­i­cy changes, proac­tive ac­tions to­day will help pro­tect your sys­tems from po­ten­tial at­tacks. As al­ways, it is vi­tal to con­tin­ue mon­i­tor­ing and up­dat­ing se­cu­ri­ty mea­sures to stay ahead of emerg­ing threats and en­sure a se­cure dig­i­tal en­vi­ron­ment in 2025 and be­yond.